WO2012127633A1 - 移動管理装置、移動管理方法および移動管理プログラム - Google Patents

移動管理装置、移動管理方法および移動管理プログラム Download PDF

Info

Publication number
WO2012127633A1
WO2012127633A1 PCT/JP2011/056851 JP2011056851W WO2012127633A1 WO 2012127633 A1 WO2012127633 A1 WO 2012127633A1 JP 2011056851 W JP2011056851 W JP 2011056851W WO 2012127633 A1 WO2012127633 A1 WO 2012127633A1
Authority
WO
WIPO (PCT)
Prior art keywords
migration
host
guest
movement
virtual machine
Prior art date
Application number
PCT/JP2011/056851
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 EP11861444.5A priority Critical patent/EP2690553A4/en
Priority to JP2013505703A priority patent/JP5804050B2/ja
Priority to PCT/JP2011/056851 priority patent/WO2012127633A1/ja
Publication of WO2012127633A1 publication Critical patent/WO2012127633A1/ja
Priority to US14/031,410 priority patent/US9244731B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G06F9/4856—Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5072—Grid computing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing

Definitions

  • the present invention relates to a mobility management device, a mobility management method, and a mobility management program.
  • the VM host is a program that virtually realizes the operating environment of the computer system.
  • the VM guest operates as a virtual machine in the environment provided by the VM host, and is responsible for processing provided to the user. This VM guest can continue processing even if it is moved to a different VM host.
  • migration such as live migration for moving the VM guest without stopping the operation or cold migration for moving the VM guest after stopping the operation is used. Yes. Note that migration is used not only for VM guests, but also for moving VM hosts to other physical servers.
  • a technology has been used in which a migration target VM guest is specified one by one using a GUI (Graphical User Interface), CLI (Command Line Interface), Script, etc., and the migration target VM host is designated. Yes.
  • GUI Graphic User Interface
  • CLI Common Line Interface
  • Script etc.
  • the virtualization software on the server to which the VM guest can be moved is specified based on the CPU usage rate, the memory usage amount, and the time required for the movement of each server that is the migration destination target of the VM guest.
  • a technique for performing live migration of a migration target VM guest on the specified virtualization software is known.
  • an object of the present invention is to provide a movement management apparatus, a movement management method, and a movement management program that can reduce the work time of movement processing of a virtual machine.
  • the movement management device includes a first determination unit that simulates movement of each virtual machine to be moved and determines a movement destination.
  • the migration management apparatus includes a second determination unit that determines a migration method of the virtual machine based on a power state of the virtual machine whose migration destination is determined by the first determination unit. The migration management apparatus, when a migration destination and a migration method are determined for each virtual machine that is the migration target, a migration method determined by the second determination unit to a migration destination determined by the first determination unit And a movement processing unit for moving each of the virtual machines.
  • FIG. 1 is a diagram illustrating an overall configuration of a system including a mobility management apparatus according to the first embodiment.
  • FIG. 2 is a block diagram illustrating a configuration of each device forming a system including a mobility management device according to the second embodiment.
  • FIG. 3 is a diagram illustrating an example of the src_vm_hosts variable stored in the variable management table.
  • FIG. 4 is a diagram illustrating an example of the src_vm_guests variable stored in the variable management table.
  • FIG. 5 is a diagram illustrating an example of the dst_vm_hosts variable stored in the variable management table.
  • FIG. 6 is a diagram illustrating an example of the migration_lists variable stored in the variable management table.
  • FIG. 7 is a diagram illustrating an example of information stored in the VM host table.
  • FIG. 8 is a diagram illustrating an example of information stored in the VM table.
  • FIG. 9 is a diagram illustrating an example of information stored in the VM guest table.
  • FIG. 10 is a diagram illustrating an example of information stored in the server profile table.
  • FIG. 11 is a diagram illustrating an example of information stored in the VM management table.
  • FIG. 12 is a diagram illustrating an example of information stored in the management software table.
  • FIG. 13 is a diagram showing an example of a TOP screen for migration processing.
  • FIG. 14 is a flowchart for explaining the overall flow of processing executed by the mobility management apparatus.
  • FIG. 15 is a flowchart for explaining the flow of the VM guest candidate generation process.
  • FIG. 16 is a flowchart for explaining the flow of the migration destination candidate VM host list generation process.
  • FIG. 17 is a flowchart for explaining the flow of the moveability determination process.
  • FIG. 18 is a flowchart for explaining the flow of the movement type determination process.
  • FIG. 19 is a diagram illustrating an example of a TOP screen.
  • FIG. 20 is a diagram illustrating an example of a screen on which a migration target VM guest list is displayed.
  • FIG. 21 is a diagram illustrating a screen example in which a list of migration destination candidate VM hosts is displayed.
  • FIG. 22 is a diagram illustrating a screen example in which one VM host is selected as a migration destination candidate.
  • FIG. 23 is a diagram illustrating an example of a screen on which a migration destination VM host is determined.
  • FIG. 24 is a diagram illustrating an example of a screen on which the movement type is determined.
  • FIG. 25 is a diagram showing an example of the TOP screen.
  • FIG. 26 is a diagram illustrating an example of a screen on which a migration target VM guest list is displayed.
  • FIG. 27 is a diagram illustrating a screen example in which a list of migration destination candidate VM hosts is displayed.
  • FIG. 28 is a diagram illustrating a screen example in which one VM host is selected as a migration destination candidate.
  • FIG. 29 is a diagram illustrating an example of a screen on which a migration destination VM host is determined.
  • FIG. 30 is a diagram illustrating an example of a screen on which the movement type is determined.
  • FIG. 25 is a diagram showing an example of the TOP screen.
  • FIG. 26 is a diagram illustrating an example of a screen on which a migration target VM guest list is displayed.
  • FIG. 27 is a diagram illustrating a screen example in which a list of migration destination
  • FIG. 31 is a diagram illustrating a screen example in which another migration source VM host is selected in a state where the migration of another VM guest has already been determined.
  • FIG. 32 is a diagram illustrating a screen example in which a migration target VM guest is selected from the state of FIG.
  • FIG. 33 is a diagram illustrating a screen example in which a migration destination candidate VM host is selected from the state of FIG.
  • FIG. 34 is a diagram showing an example of a screen determined by the migration destination VM host from the state of FIG.
  • FIG. 35 is a diagram showing an example of a screen in which the movement type is determined from the state of FIG.
  • FIG. 36 is a diagram showing an example of a screen for determining the migration destination of another VM guest further from the state of FIG.
  • FIG. 37 is a diagram showing a screen example in which a migration target VM guest is selected from the state of FIG.
  • FIG. 38 is a diagram illustrating an example of a screen in which another VM guest has already been decided to be migrated to the VM host selected as the migration destination candidate.
  • FIG. 39 is a diagram showing an example of a screen in which the movement type is determined from the state of FIG.
  • FIG. 40 is a diagram illustrating an example of a screen in which it is determined that a plurality of VM guests are moved to one VM host.
  • FIG. 41 is a diagram illustrating an example of a computer that executes a mobility management program.
  • FIG. 1 is a diagram illustrating an overall configuration of a system including a mobility management apparatus according to the first embodiment.
  • the system includes a client device 10, a mobility management device 30, a VM (Virtual Machine) management device 50, a VM management device 70, and a plurality of servers (VM hosts) 60.
  • VM Virtual Machine
  • FIG. 1 the number of servers and the number of devices illustrated in FIG. 1 are merely examples, and the present invention is not limited to this, and an arbitrary number can be set.
  • the client device 10 is a computer used by an administrator or user of this system, and transmits a VM guest migration instruction to the migration management device 30 to execute migration of the VM guest.
  • the migration management device 30 includes a first determination unit 30a, a second determination unit 30b, and a migration processing unit 30c.
  • the migration management device 30 receives a VM guest migration instruction from the client device 10 and sends it to the VM management device 50 and the VM management device 70. , Request execution of VM guest migration.
  • the VM management device 50 and the VM management device 70 are servers that manage the entire virtual machine by storing information on the VM host operating on the physical server and the VM guest operating on the VM host. .
  • the VM management device 50 and the VM management device 70 store information on the VM host such as the resource status of the VM host and the VM guest, and the maximum number of VM guests that can operate on the VM host.
  • the server 60 is a physical server that executes a VM host that is a program that virtually operates an operating environment of another computer system that operates a VM guest that is a virtual machine.
  • the VM guest is a virtual machine responsible for processing provided to the user in the environment provided by the VM host.
  • the first determination unit 30a of the migration management apparatus 30 determines the migration destination VM host by simulating the migration of the VM guest for each migration target VM guest.
  • the second determination unit 30b determines the migration method of the VM guest based on the power state of the VM guest whose migration destination VM host has been determined.
  • the migration method determined by the second determination unit 30b is used as the migration destination determined by the first determination unit 30a. , VM guests are moved together.
  • FIG. 2 is a block diagram illustrating a configuration of each device forming a system including a mobility management device according to the second embodiment. Since the VM management device 50 and the VM management device 70 have the same configuration, here, the VM management device 50 will be described as an example. Similarly, since each server shown in FIG. 1 has the same configuration, the server 60 will be described as an example here.
  • the mobility management device 30 includes a communication control I / F unit 31, an input unit 32, a display unit 33, a storage unit 34, and each control unit.
  • Each control unit is, for example, an electronic circuit such as a CPU, and includes a VM host generation unit 35, a VM guest candidate generation unit 36, a movement destination candidate generation unit 37, a movement determination unit 38, a movement type determination unit 39, and a movement instruction unit. 40.
  • the communication control I / F unit 31 is an interface that has at least one port and controls communication with other devices.
  • the communication control I / F unit 31 is connected to the client device 10, receives a VM guest migration process start instruction, and outputs the received instruction to each control unit.
  • the communication control I / F unit 31 is connected to the VM management device 50 and the VM management device 70, and transmits a VM guest migration instruction instructed by the migration instruction unit 40 to the VM management device 50 and the VM management device 70. To do.
  • the communication control I / F unit 31 receives the migration result from the VM management device 50 or the VM management device 70.
  • the communication control I / F unit 31 transmits the Web screen generated by each control unit to the client device 10.
  • the input unit 32 is, for example, an input device such as a keyboard or a mouse, and realizes a pointing device function in cooperation with the display unit 33.
  • the input unit 32 receives input to an input screen or a selection screen displayed on the display unit 33, It outputs to the display part 33 and each control part.
  • the input unit 32 accepts selection of a migration target VM host or VM guest, migration type selection, and the like.
  • the display unit 33 is a display device such as a display, for example, and displays a web screen generated by each control unit.
  • the storage unit 34 is a storage device such as a semiconductor memory element or a hard disk.
  • the storage unit 34 includes a variable management table 34a, a VM host table 34b, a VM table 34c, a VM guest table 34d, a server profile table 34e, a VM management table 34f, and a management software table 34g.
  • a management software table 34g Note that the information exemplified in the description of each table is merely an example, and is not limited to this, and can be arbitrarily changed. Information stored in each table may be updated by an administrator or the like, or may be periodically updated by the VM management apparatus 30.
  • the variable management table 34a stores variables used when each control unit executes processing.
  • the variable management table 34a stores a src_vm_hosts variable, a src_vm_guests variable, a dst_vm_hosts variable, and a migration_lists variable.
  • the information shown in FIGS. 3 to 6 can be arbitrarily changed, such as an IP (Internet Protocol) address or a MAC (Media Access Control) address instead of the host name.
  • the src_vm_hosts variable is used when the VM host generation unit 35 or the like generates a Web screen that displays the migration source VM host.
  • FIG. 3 is a diagram illustrating an example of the src_vm_hosts variable stored in the variable management table.
  • the variable management table 34 a stores “array_index, ID, NAME” as a src_vm_hosts variable.
  • Array_index” stored here is an identifier for identifying the position of the array to be stored
  • ID is an identifier used to distinguish the VM host
  • NAME is the name of the migration source VM host. It is a host name.
  • the src_vm_guests variable is used when the VM guest candidate generation unit 36 or the like generates a Web screen that displays a VM guest to be moved.
  • FIG. 4 is a diagram illustrating an example of the src_vm_guests variable stored in the variable management table. 4 indicates a list of migration candidate VM guests, and s2 in FIG. 4 indicates a state after “Guest_c1” is determined as a transfer target from the state of s1. As illustrated in FIG. 4, the variable management table 34 a stores “Hash_key, array_index, ID, NAME” as the src_vm_guests variable.
  • “Hash_key” stored here is an identifier for identifying a VM host on which a VM guest stored in “NAME” operates, and “array_index” is an identifier for identifying a storage location. Further, “ID” is an identifier used to distinguish VM guests, and “NAME” is the name of a migration candidate VM guest.
  • the dst_vm_hosts variable is used when the migration destination candidate creation unit 37 or the like creates a Web screen that displays a migration destination candidate VM host.
  • FIG. 5 is a diagram illustrating an example of the dst_vm_hosts variable stored in the variable management table. Note that s3 in FIG. 5 shows a list of VM hosts that are migration destination candidates, and s4 in FIG. 5 is a list of VM hosts that become migration destination candidates after “Guest_b2” is determined as a migration target from the state of s3. Is shown. As illustrated in FIG. 5, the variable management table 34 a stores “Hash_key, array_index, ID, NAME” as the dst_vm_hosts variable.
  • “Hash_key” stored here is an identifier for identifying a host as a migration source
  • “array_index” is an identifier for identifying a storage location.
  • ID is an identifier used to distinguish the migration destination candidate VM host
  • NAME is the host name of the migration destination candidate VM host.
  • the migration destination candidate creation unit 37 adds the VM hosts “Host_f” and “Host_g” to the dst_vm_hosts variable as migration destination candidates for the VM guest “Guest_b2” determined as the migration target.
  • the migration_lists variable is used when the migration determination unit 38 or the like determines the migration method of the migration target VM guest, or when the migration instruction unit 40 transmits a migration instruction.
  • FIG. 6 is a diagram illustrating an example of the migration_lists variable stored in the variable management table.
  • the variable management table 34a stores “Hash_key, array_index, ID, migration_type” as a migration_lists variable.
  • “Hash_key” stored here is an identifier for identifying a VM host as a migration destination
  • array_index is an identifier for identifying a storage location.
  • ID is an identifier used for distinguishing VM guests
  • migration_type is information indicating a migration method.
  • the VM host table 34b stores a list of VM hosts managed by the mobility management device 30.
  • FIG. 7 is a diagram illustrating an example of information stored in the VM host table 34b. As illustrated in FIG. 7, the VM host table 34 b stores “ID, NAME, api_type, virtual_machines, logical_server_id (SV)” in association with each other as VM host information. Note that the information stored here may be updated as needed by a manager or the like manually or by a job, or the mobility management device 30 may periodically acquire from each VM management device.
  • ID stored here is an identifier for identifying information stored in the VM host table 34b
  • NAME is a host name of the VM host.
  • Api_type indicates the type of API (Application Programming Interface) for realizing the VM host and operating the VM guest.
  • Virtual_machines is information indicating the operating VM guests, and is stored in an array.
  • Logical_server_id (SV)” is an identifier that identifies a record in a server profile table to be described later.
  • the VM table 34c stores detailed information on VM guests operating as virtual machines on the VM host.
  • FIG. 8 is a diagram illustrating an example of information stored in the VM table. As illustrated in FIG. 8, the VM table 34 c stores “ID, os_instance, power_status, vm_host_id, memory capacity, number of CPUs, and CPU specifications” as detailed information related to the VM guest in association with each other.
  • the “ID” stored here is an identifier for identifying each record of the VM table 34c
  • “os_instance” is information indicating the link destination of the VM guest object, and identifies the VM guest operating as a virtual machine.
  • “Power_status” indicates the power status of the virtual machine, in other words, the VM guest, “ON” when the power is on, “OFF” when the power is off, and when the power status cannot be detected.
  • “Vm_host_id” is information for specifying the VM host on which the VM guest operates, and stores the ID of the VM host table 34b.
  • Memory capacity is the memory capacity assigned to the VM guest
  • CPU number is the number of CPUs assigned to the VM guest.
  • the “CPU spec” is information indicating the performance of the CPU assigned to the VM guest, and here, an example in which the clock frequency of the CPU is stored is shown.
  • the VM guest table 34d stores information on VM guests.
  • FIG. 9 is a diagram illustrating an example of information stored in the VM guest table.
  • the VM guest table 34 d stores “ID, NAME, logical_server_id (VM)” in association with each other as information related to the VM guest.
  • the “ID” stored here is an identifier for uniquely identifying the VM guest, and “NAME” is a name indicated by the VM guest.
  • “Logical_server_id (VM)” is an identifier used when specifying a VM host, and stores “ID” stored in the VM table 34c.
  • the information regarding the VM guest “Guest_b1” whose ID is “21” corresponds to the record whose I is “101” in the VM table 34c.
  • information regarding the VM guest “Guest_c1” whose ID is “25” corresponds to a record whose ID is “105” in the VM table 34c.
  • the server profile table 34e stores information on VM management software that can be used in the VM host for each VM host.
  • FIG. 10 is a diagram illustrating an example of information stored in the server profile table 34e. As illustrated in FIG. 10, the server profile table 34e stores “ID, os_instance, vm_managings” in association with each other as VM host information.
  • ID stored here is a record stored in the server profile table 34e, in other words, an identifier for identifying a VM host.
  • Os_instance is information indicating the link destination of the VM host object, and is information specifying the VM host on which the VM guest operates.
  • Vm_managings indicates VM management software that can be used by the VM host, in other words, an API type that can be handled by the VM host, and is stored as an array.
  • the VM host “Host_a” whose ID is “1” corresponds to AP1, AP2, and AP4. Note that “omitted” described in FIG. 10 indicates that the description is simply omitted for the sake of explanation, and generally information such as AP1 is stored.
  • the VM management table 34f stores information for specifying the software group to which the VM management software of the VM host stored in the server profile table 34e belongs.
  • FIG. 11 is a diagram illustrating an example of information stored in the VM management table. As illustrated in FIG. 11, the VM management table 34 f stores “ID, management_software_id, logical_server_id (SV)” in association with each other.
  • ID stored here is an identifier for identifying each record of the server profile table 34e
  • management_software_id is information for specifying a software group to which the VM management software belongs.
  • Logical_server_id (SV) is an identifier that identifies a record in the server profile table. Referring to the example of FIG. 11, the record with ID “1” indicates that the record with ID “8” in the server profile table 34e belongs to the software group “1”. Similarly, the record with ID “3” indicates that the record with ID “9” in the server profile table 34 e belongs to the software group “2”.
  • the management software table 34g stores a software group of VM management software.
  • FIG. 12 is a diagram illustrating an example of information stored in the management software table. As illustrated in FIG. 12, the management software table 34g stores “1, Managing1, Managing3”, “2, Managing2”, and the like as “ID, managings”.
  • the “ID” stored here is an identifier that identifies each record of the management software table 34g and identifies “managings”, and is the same identifier as the identifier stored in “management_software_id” of the VM management table 34f.
  • “Managings” indicates a software group of the VM management software. In the example of FIG. 12, “Managing1” and “Managing3” which are VM management software belong to the same group with ID “1”, and “Managing2” belongs to the group with ID “2”. .
  • the VM host generation unit 35 generates a list of VM hosts that are migration sources. For example, when the VM guest migration processing start instruction transmitted from the client device 10 is received by the communication control I / F unit 31 or the like, the VM host generation unit 35 transmits the Web screen illustrated in FIG. 13 to the client device 10. .
  • FIG. 13 is a diagram showing an example of a TOP screen for migration processing.
  • the TOP screen shown in FIG. 13 has a “Source VM Host List” field, a “Source VM Guest List” field, a “Target VM Host List” field, a “Cold Migration” field, and a “Live Migration” field.
  • Each field may be provided with a scroll for moving the display content up, down, left and right.
  • a list of migration source VM hosts is displayed.
  • a list of VM guests operating on the VM host selected by the user is displayed as the migration target candidate VM guests. Is done.
  • a list of VM hosts that are migration destination candidates for the VM guest specified as the migration target is displayed.
  • the “Cold Migration” field displays a list of VM guests whose migration type is determined to be cold migration among the VM guests determined by the migration destination VM host.
  • “Live Migration” field a list of VM guests whose migration type is determined to be live migration among the VM guests determined by the migration destination VM host is displayed.
  • the “OK” button is clicked, migration of the VM guest displayed in the “Cold Migration” field and the “Live Migration” field is started.
  • the “Cancel” button is clicked, the migration process ends.
  • the VM host generation unit 35 that displays the TOP screen acquires the VM host name from “NAME” in each record of the VM host table 34b. Then, the VM host generation unit 35 generates a screen in which each acquired VM host name is displayed in the “Source VM Host List” field of the TOP screen, and transmits the screen to the client device 10. At this time, the VM host generation unit 35 sequentially acquires “ID” and “NAME” in the VM host table 34b in association with each other, and stores them sequentially from the array “0” of the src_vm_hosts variable.
  • the storage order is not limited to the ascending order of the array element numbers, but may be randomly acquired and stored in the array randomly.
  • the VM host generation unit 35 acquires “NAME” shown in FIG. 7 and generates an icon or the like on which the acquired “NAME” is displayed. Then, the VM host generation unit 35 generates a screen in which the generated icon is displayed in the “Source VM Host List” field, and transmits the screen to the client device 10. Also, the VM host generation unit 35 stores “ID” and “NAME” of the VM host table 34b in the array of the src_vm_hosts variable in the order of the generated icons. Specifically, the VM host generation unit 35 stores “NAME” and “ID” displayed in the first generated icon in the array “0” and is displayed in the second generated icon. Store “NAME” and “ID” in array “1”. In this way, the VM host generation unit 35 can associate icons with table information.
  • the VM guest candidate generation unit 36 generates a list of VM guests that are candidates for migration. For example, the VM guest candidate generation unit 36 selects a user from the VM host displayed in the “Source VM Host List” field on the screen displayed by the VM host generation unit 35 via the communication control unit I / F unit 31. Accept. Then, the VM guest candidate creation unit 36 extracts a VM guest operating on the selected VM host, and transmits a screen in which the extracted VM guest is displayed in the “Source VM Guest List” field to the client device 10. .
  • the VM guest candidate creation unit 36 creates a src_vm_guests variable when the migration source VM host list is displayed by the VM host creation unit 35.
  • the VM guest candidate creation unit 36 specifies the clicked VM host from the array of src_vm_hosts variables corresponding to the icon.
  • the VM guest candidate generation unit 36 generates an icon displaying the VM guest name stored in “NAME” of the src_vm_guests variable in association with the identified VM host.
  • the VM guest candidate generation unit 36 transmits a screen in which the generated icon is displayed in the “Source VM Guest List” field to the client device 10. That is, the VM guest candidate creation unit 36 displays the VM guest operating on the selected VM host as a migration target candidate VM guest to the user.
  • the VM guest candidate creation unit 36 may not store the VM guest whose “power_status” is “unkown” in the src_vm_guests variable. For example, since the “power_status” of “Guest_b4” illustrated in FIG. 8 is “unkown”, the VM guest candidate generation unit 36 stores “Guest_b4” in the src_vm_guests variable as illustrated in s1 of FIG. Not done.
  • a migration target candidate VM guest when the user selects a VM host in a state where the VM guest candidate generation unit 36 has generated the src_vm_guests variable will be described.
  • the VM guest candidate generation unit 36 specifies the clicked VM host from the array of src_vm_hosts variables corresponding to the icon.
  • the migration destination candidate generation unit 37 generates a list of VM hosts that are migration destination target candidates when a migration target VM guest is determined. Specifically, the migration destination candidate generation unit 37 identifies a migration target VM guest by user selection, creates a migration destination candidate for the identified VM guest, and displays it to the user.
  • the migration destination candidate generation unit 37 refers to the VM management table 34f and the management software table 34g to identify the group “manageings” to which the VM management software of the migration source VM host belongs.
  • the migration destination candidate generation unit 37 can also make a VM host belonging to the same group as the identified group “manageings” a migration destination candidate.
  • the movement determination unit 38 executes a movement simulation on the VM host specified as the movement destination of the movement target VM guest, and determines whether or not the movement is possible. For example, the movement determination unit 38 first accepts a user's selection from the screen generated by the movement destination candidate generation unit 37 and specifies a VM host that is a movement destination candidate. Next, using the resource status of the migration target VM guest specified by the migration destination candidate generation unit 37, the migration determination unit 38 executes migration simulation on the migration destination candidate VM host to determine whether the migration is possible. To do. After that, if it is determined that the movement is possible, the movement determination unit 38 notifies the movement type determination unit 39 to that effect and shifts the processing. If it is determined that the movement is impossible, the movement determination unit 38 notifies the user of that fact. To select another VM host.
  • the migration determination unit 38 identifies the migration destination candidate VM host as “Host_c”. In other words, the migration determination unit 38 specifies that the migration target VM guest is “Guest_b2” and the migration destination candidate VM host is “Host_c”.
  • the movement determination unit 38 issues a migration command “Guest_b2” to “Host_c” and determines whether the movement is possible.
  • the movement determination unit 38 can determine whether the number of VM guests operating in “Host_c” does not exceed the upper limit of “Host_c”.
  • the migration determination unit 38 acquires the resource status of “Host_c” from the VM management apparatus, acquires the resource status of “Guest_b2” from the VM table 34c, and determines whether “Guest_b2” is operable in “Host_c”.
  • the resource status includes the number of CPUs, memory capacity, network bandwidth, and the like.
  • the migration determination unit 38 determines whether the VM management software running on the migration destination candidate VM host “Host_c” is software that supports multiple migrations. Determine whether. For example, the migration determination unit 38 refers to the server profile table 34e and extracts “ID” associated with the migration destination candidate VM host “Host_c”. Then, the movement determination unit 38 extracts “management_software_id” associated with the extracted “ID” from the VM management table 34f. Furthermore, the movement determination unit 38 identifies “managings” associated with the extracted “management_software_id” from the management software table 34g. Then, the movement determination unit 38 determines whether or not the specified “managings” is a software type corresponding to a plurality of migrations based on information registered in a memory or the like by the Internet or an administrator. .
  • “Guest_b2” is determined from the resource status of “Host_c” and the resource status of another VM guest that has already been determined to migrate. Identify the resource status that can be used. Thereafter, the movement determination unit 38 determines whether or not “Guest_b2” can be moved to “Host_c” depending on whether or not “Guest_b2” is operable under the specified resource status. As another example, the migration determination unit 38 can simultaneously issue “Guest_b2” and a migration command of another VM guest to determine whether or not an error occurs.
  • the migration determination unit 38 determines that the software does not support multiple migrations, the migration determination unit 38 adds one resource status of another VM guest that has already been migrated and the resource status of “Guest_b2”. Generate resource status. Then, the movement determination unit 38 determines that “Guest_b2” is movable when the generated one resource status is within the range of the resource status of “Host_c”. On the other hand, when the generated one resource status is not within the range of the resource status of “Host_c”, the migration determination unit 38 can move another VM guest to “Host_c”, and “Guest_b2” is “Host_c”. It is determined that it is impossible to move.
  • the migration determination unit 38 can acquire the resource status of other VM guests and the resource status of “Guest_b2” from the VM table 34 c, and can acquire the resource information of “Host_c” from the VM management devices 50 and 70. it can. In this way, the movement determination unit 38 identifies the movement destination of the VM guest.
  • the migration type determination unit 39 determines the migration type of the migration target VM guest identified by the migration determination unit 38. Specifically, the migration type determination unit 39 refers to the VM table 34c and determines that the migration type of the VM guest is “live migration” when the power status of the migration target VM guest is “ON”. To do. Further, the migration type determination unit 39 refers to the VM table 34c, and determines the migration type of the VM guest as “cold migration” when the power status of the migration target VM guest is “OFF”. In addition, the migration type determination unit 39 refers to the VM table 34c and notifies the user that the migration of the VM guest is “impossible” when the power status of the migration target VM guest is “unknown”. Alternatively, the movement type may be determined as “cold migration”.
  • the migration type determination unit 39 acquires “NAME” of the VM guest whose migration type is determined to be “cold migration” from the VM guest table 34d and generates an icon or the like. Thereafter, the movement type determination unit 39 displays the generated icon or the like in the “Cold Migration” field on the screen. Similarly, the migration type determination unit 39 acquires “NAME” of a VM guest whose migration type is determined to be “live migration” from the VM guest table 34d and generates an icon or the like. Thereafter, the movement type determination unit 39 displays the generated icon or the like in the “Live Migration” field on the screen. Thereafter, the movement type determination unit 39 transmits a screen on which the generated icon is displayed to the client device 10.
  • the migration type determination unit 39 obtains “Hash_key” of the migration destination VM host from the VM host table 34b and the like, and obtains “ID” of the migration target VM guest from the VM guest table 34e and the like. Then, the migration type determination unit 39 stores “Hash_key” and “ID” in association with the determined “migration type” in the migration_lists variable.
  • the movement instruction unit 40 moves the movement method determined by the movement type determination unit 39 to the movement destination determined by the movement type determination unit 39 when the movement destination and the movement method are determined for each VM guest to be moved. Then, each VM guest is moved.
  • the VM management device 50 includes a communication control I / F unit 51, a VM configuration management table 52, and a control unit 53.
  • the communication control I / F unit 51 has at least one port, and is an interface that controls communication between the mobility management device 30 and the VM management device 50 and communication between each server 60 and the VM management device 50. is there.
  • the communication control I / F unit 51 receives a VM guest migration instruction from the VM management apparatus 50 and transmits / receives various communications related to migration with each VM host.
  • the VM configuration management table 52 is a storage device such as a semiconductor memory device or a hard disk, and stores information related to VM hosts and VM guests under the management of the VM management device 50.
  • the VM configuration management table 52 includes the IP address of the server, the VM host operating on the server, the VM management software that provides the VM environment, the resource status available on the VM host, the number of operating VM guests, and each resource Memorize the situation.
  • the information stored here can be arbitrarily changed, registered or updated by an administrator or the like, and may be periodically acquired from each server.
  • the control unit 53 of the VM management device 50 may periodically transmit the information stored in the VM configuration management table 52 to the movement management device 30.
  • the control unit 53 is an electronic circuit such as a CPU having an internal memory or the like, and controls various processes executed by the VM management device 50. For example, the control unit 53 receives “migration type”, “VM guest”, and “VM host” as migration instructions from the migration management apparatus 30. If the “migration type” is “cold”, the control unit 53 transmits a cold migration instruction to the migration source VM host and the migration destination VM host of the designated VM guest. Since the migration executed here is a general migration, detailed description thereof is omitted.
  • the migration instruction includes an instruction to create a migration target VM guest, a pre-copy instruction and a stop-and-copy instruction to copy memory contents, an instruction to start a VM guest that has been migrated, and a VM guest deletion instruction to the migration source.
  • the server 60 includes a communication control I / F unit 61 and a control unit 62.
  • the communication control I / F unit 61 is an interface that has at least one port and controls communication between the server 60 and the VM management device 50.
  • the communication control I / F unit 61 receives the migration instruction from the VM management apparatus 50 and notifies the control unit 62 of it.
  • the control unit 62 is an electronic circuit such as a CPU having an internal memory or the like, and executes various processes in the server 60.
  • the control unit 62 operates VM management software to execute a VM host, and operates a VM guest on the VM host to realize a virtual machine environment.
  • the control unit 62 executes migration processing such as VM guest creation, pre-copy, stop-and-copy, VM activation, and VM deletion according to the migration instruction received from the VM management device 50.
  • FIG. 14 is a flowchart for explaining the overall flow of processing executed by the mobility management device 30.
  • the VM host generation unit 35 of the mobility management device 30 transmits the TOP screen illustrated in FIG. 13 to the client device 10 ( S102).
  • the VM processing start instruction can also be received from the administrator via the input unit 32.
  • the VM host generation unit 35 transmits a screen in which the VM host name is displayed in the “Source VM Host List” field of the TOP screen to the client device 10, and accepts selection of the migration source VM host (S103). For example, when receiving the VM processing start instruction, the VM host generation unit 35 stores the VM host stored in the VM host table 34b in the src_vm_hosts variable, and transmits a screen for selecting the migration source VM host to the client apparatus 10. .
  • the client device displays a screen in which the VM guest operating on the selected VM host is displayed in the “Source VM Guest List” field. 10 (S104).
  • the migration destination candidate generation unit 37 accepts selection of a VM guest to be moved on the screen generated by the VM guest candidate generation unit 36 (Yes in S105). Thereafter, the migration destination candidate generation unit 37 transmits a screen displaying the migration destination candidates of the selected VM guest in the “Target VM Host List” field to the client device 10 (S106). At this time, the migration destination candidate generation unit 37 determines a migration destination candidate VM host based on the VM management software of the migration source VM host or the like.
  • the movement determination unit 38 receives selection of a VM host as a movement destination candidate on the screen generated by the movement destination candidate generation unit 37 (Yes in S107). Thereafter, the migration determination unit 38 determines by simulation whether or not the VM guest selected in S103 can be migrated to the VM host selected in S107 (S108).
  • the migration type determination unit 39 determines the VM host determined to be movable by the migration determination unit 38 as a migration destination (Yes in S109), and determines the migration type according to the power state of the VM guest selected in S103. (S110). On the other hand, if it is determined that the migration to the VM host selected by the user is impossible (No at S109), the migration determination unit 38 returns to S106, causes the user to select another VM host, and then the processing after S107. Execute.
  • the movement instructing unit 40 determines that the processing from S103 to S110 has been completed for all VM guests to be moved (Yes in S111), and the “OK” button is displayed on the screen displayed on the client device 10. Is clicked (S112 affirmative), S113 is executed. That is, the movement instruction unit 40 is determined by the movement type determination unit 39 as the movement destination determined by the movement type determination unit 39 when the movement destination and the movement method are determined for each VM guest to be moved. Each VM guest is moved by the movement method. On the other hand, when it is determined that the process from S103 to S110 is executed for other VM guests (No at S111), the processes after S103 are repeated.
  • FIG. 15 is a flowchart for explaining the flow of the VM guest candidate generation process. This process is executed in S104 to S105 shown in FIG. The flowchart described below is executed from a state where one VM host is selected from the VM host list displayed by the VM host generation unit 35.
  • the VM guest candidate generation unit 36 performs initialization when the process is started (S201). That is, the VM guest candidate generation unit 36 empties the src_vm_guests variable. In addition, the VM guest candidate generation unit 36 specifies and stores the VM guest that operates on the VM host selected by the user from the VM host table 34b and the VM guest table 34d in the investigation list used to generate the src_vm_guests variable. To do.
  • the VM guest candidate generation unit 36 when information is stored in the survey list (Yes in S202), the VM guest candidate generation unit 36 generates a screen displaying the movement target candidates and transmits the screen to the client device 10. That is, the VM guest candidate generation unit 36 displays the movement target candidates based on the data stored in the src_vm_guests variable (S207).
  • the VM guest candidate generation unit 36 reads one VM guest from the survey list and stores it as a temporary variable in a memory or the like (S203).
  • the VM guest candidate generation unit 36 specifies the power state of the VM guest stored in the temporary variable from the VM table 34c, and determines whether the power state is normal (S204).
  • the VM guest candidate generation unit 36 determines that the VM guest is normal when the power state of the VM guest is not “unknown”.
  • the VM guest candidate generation unit 36 stores the VM guest as a movable candidate in the src_vm_guests variable (S205), and sets the temporary variable to empty. (S206), the process after S202 is repeated.
  • the VM guest candidate generation unit 36 empties the temporary variable without setting the VM guest as a movable candidate (S206), and after S202 Repeat the process.
  • FIG. 16 is a flowchart for explaining the flow of the migration destination candidate VM host list generation process. This process is executed in S106 to S107 shown in FIG.
  • the migration destination candidate creation unit 37 performs initialization to empty the “management software list” and “migration destination VM host candidate list”, which are temporary buffers used to create the migration destination candidate VM host list. Execute (S303).
  • the migration destination candidate generation unit 37 determines whether or not “api_type” of the migration source VM host identified in S302 is predetermined management software (S304). Then, when the “api_type” of the migration source VM host is predetermined management software (Yes in S304), the migration destination candidate generation unit 37 identifies the VM host that operates the predetermined management software from the VM host table 34b, It is stored in the “migration destination VM host candidate list” (S305). At this time, the migration destination candidate generation unit 37 also stores the information stored in the “migration destination VM host candidate list” in the dst_vm_hosts variable. Thereafter, the migration destination candidate creation unit 37 displays the VM hosts stored in the “migration destination VM host candidate list” and the dst_vm_hosts variable on the client device 10 as migration destination candidate VM hosts (S306).
  • the migration destination VM host candidate after determining whether or not the management software is predetermined, for example, it is determined whether or not the management software of the same manufacturer as that of the migration source VM host is used. Also good. It is also possible to determine whether the platform of the virtualization software that provides the virtualization environment is the same, that is, whether it is provided at the hardware level, provided at the software level, or at the language level. Good. As another example of processing executed in S304 and S305, the migration destination candidate generation unit 37 may specify a VM host that operates the same management software as the management software of the migration source VM host.
  • the migration destination candidate generation unit 37 stores the management software of the migration source VM host in the “management software list” (S307). That is, the migration destination candidate generation unit 37 identifies management software installed and operating on the migration source VM host from the server profile table 34e, and stores it in the “management software list”.
  • the destination candidate generation unit 37 acquires one management software from the “management software list” and makes it a temporary variable. Store (S309). At this time, the destination candidate generation unit 37 deletes the management software stored in the temporary variable from the “management software list”. If there is no management software stored in the “management software list” (No at S308), the destination candidate generation unit 37 executes S312.
  • the migration destination candidate generation unit 37 determines whether or not there is one or more VM hosts managed by the management software stored in the temporary variable (S310). Specifically, the migration destination candidate generation unit 37 specifies the software group to which the management software stored in the temporary variable belongs from the management software table 34g. Then, the migration destination candidate creation unit 37 identifies the VM host that operates the management software belonging to the identified software table from the VM management table 34f and the VM table 34c. In this way, the migration destination candidate generation unit 37 can specify a VM host that provides the same type of virtual environment as the migration source VM host.
  • the migration destination candidate generation unit 37 selects the VM host managed by the management software as “move destination VM host candidate list”. (S311). At this time, the migration destination candidate generation unit 37 excludes the migration source VM host from the storage target. Further, the migration destination candidate generation unit 37 also stores the information stored in the “migration destination VM host candidate list” in the dst_vm_hosts variable.
  • the destination candidate generation unit 37 performs initialization to delete the information stored in the temporary variable (S312), and repeats the processing after S308. If the migration destination candidate creation unit 37 determines in S310 that there is no VM host managed by the management software stored in the temporary variable (No in S310), it executes S312.
  • FIG. 17 is a flowchart for explaining the flow of the moveability determination process. This process is executed in S108 to S109 shown in FIG.
  • the migration determination unit 38 determines whether or not the “migration-determined VM guest list” of the migration destination candidate VM host selected by the user from the migration destination candidate VM host list specified by the migration destination candidate generation unit 37 has not been set. Is determined (S401). In other words, the migration determination unit 38 determines whether or not there is a “migration-determined VM guest list” indicating whether or not there is another VM guest whose migration destination candidate VM host is the migration destination.
  • the movement determination unit 38 executes initialization of the “movement determined VM guest list” (S402). For example, the movement determination unit 38 deletes the data stored in the “migration determined VM guest list”.
  • the movement determination unit 38 transmits a screen displaying the “movement determined VM guest list” to the client device 10 (S403). By doing so, the movement determination unit 38 can give the user an opportunity to reconsider the movement-determined VM guest.
  • the migration determination unit 38 generates a “multiple VM guest list” in which VM guests whose migration destination candidate VM hosts are the migration destination are collected (S404). Subsequently, the movement determination unit 38 uses information such as “managings” stored in the VM management table 34f to determine whether or not the VM management software running on the migration destination candidate VM host supports multiple movements. Determination is made (S405).
  • the movement determination unit 38 sets a plurality of VM guests as arguments such as a migration command (S406) and executes a simulation (S407). Thereafter, the movement determination unit 38 transmits a screen displaying the simulation result to the client device 10 (S408). For example, the migration determination unit 38 performs migration of a plurality of VM guests to the same VM host at the same time, continuously, or migrates a VM guest that has been previously decided. Arbitrary simulation is executed, such as determining whether or not it is possible. The movement determination unit 38 issues a resource status comparison command as a determination method by simulation.
  • the movement determination unit 38 determines whether or not the movement condition can be moved by the migration destination candidate VM guest in S407 and subsequent steps.
  • FIG. 18 is a flowchart for explaining the flow of the movement type determination process. This process is executed in S110 shown in FIG. This process is executed for each VM guest whose migration destination has been determined.
  • the migration type determining unit 39 determines a migration type suitable for the migration target VM guest will be described, but the present invention is not limited to this.
  • an appropriate movement type can be displayed to the user, and the user can finally determine the movement type.
  • the migration type determination unit 39 deactivates the migration type of the screen displayed on the client device 10 (S501). ). That is, the movement type determination unit 39 deactivates the “Cold Migration” field and the “Live Migration” field on the screen shown in FIG.
  • the migration type determination unit 39 identifies the power status of the migration target VM guest from the VM table 34c (S502). When the power status of the VM guest is “ON”, the migration type determination unit 39 activates both the “Cold Migration” field and the “Live Migration” field (S503). Thereafter, the migration type determining unit 39 displays the icon of the VM guest in the “Live Migration” field (S504).
  • the migration type determination unit 39 activates the “Cold Migration” field when the power state of the VM guest is “OFF” (S505). After that, the migration type determination unit 39 displays the icon of the VM guest in the “Cold Migration” field (S506).
  • the migration type determination unit 39 deactivates both the “Cold Migration” field and the “Live Migration” field (S507). That is, the movement type determination unit 39 determines that movement is impossible.
  • the migration type determination unit 39 When the migration type is determined in S502 to S506, the migration type determination unit 39 “Hash_key” indicating the migration destination VM host, “ID” indicating the migration target VM guest, and “migration_type” indicating the migration type. Is obtained from each table and each variable. Then, the migration type determination unit 39 associates the acquired information and stores it in the migration_lists variable.
  • the screen examples described in each specific example include a “Source VM Host List” field, a “Source VM Guest List” field, a “Target VM Host List” field, a “Cold Migration” field, and a “Live Migration”. Field. Furthermore, the screen examples described in each specific example include an “OK” button and a “Cancel” button.
  • FIG. 19 is a diagram showing an example of a TOP screen
  • FIG. 20 is a diagram showing a screen example in which a migration target VM guest list is displayed
  • FIG. 21 is a diagram in which a migration destination candidate VM host list is displayed. It is a figure which shows the example of a screen.
  • FIG. 22 is a diagram showing an example of a screen in which one VM host is selected as a migration destination candidate
  • FIG. 23 is a diagram showing an example of a screen in which a migration destination VM host is determined
  • FIG. It is a figure which shows the example of a screen in which the classification was determined.
  • the VM host generation unit 35 of the mobility management device 30 displays the TOP screen shown in FIG. Send to. Specifically, the VM host generation unit 35 displays the VM host name (NAME) acquired from the VM host table 34b or the like in the “Source VM Host List” field on the screen having each field shown in FIG. The screen is transmitted to the client device 10.
  • NAME VM host name
  • the VM host generation unit 35 displays “Host_a”, “Host_b”, and “Host_c”.
  • the VM guest candidate creation unit 36 determines the migration source VM host as “Host_c”. Subsequently, the VM guest candidate generation unit 36 refers to each table and extracts “Guest_c1” and “Guest_c3” as VM guests operating in “Host_c”. Then, as illustrated in FIG. 20, the VM guest candidate generation unit 36 transmits a screen in which “Guest_c1” and “Guest_c3” are displayed in the “Source VM Guest List” field to the client device 10.
  • the migration destination candidate generation unit 37 refers to each table and manages the same or the same VM management as the migration source VM host “Host_c”. Specify another VM host that runs the software.
  • the migration destination candidate creation unit 37 displays a screen in which “Host_a”, “Host_d”, and “Host_e” are displayed in the “Target VM Host List” field as the migration destination candidate VM hosts. It transmits to the client device 10.
  • the movement determination unit 38 determines whether or not the migration target VM guest “Guest_c1” can be moved to “Host_a”. Judgment by. Then, when the movement determination unit 38 determines that the movement is possible, the movement type determination unit 39 specifies from the VM guest table 34e that the power state of the VM guest “Guest_c” is “ON”. Thereafter, as shown in FIG. 23, the movement type determination unit 39 transmits a screen in which the “Cold Migration” field and the “Live Migration” field are activated to the client device 10.
  • the migration type determination unit 39 displays a screen displaying “Guest_c” in the “Live Migration” field because the power state of the VM guest “Guest_c” is “ON”. 10 to send.
  • the migration instruction unit 40 refers to the migration_lists variable and is displayed in the “Live Migration” field.
  • An instruction to start moving “Guest_c” is transmitted to the VM management apparatus.
  • the VM management apparatus transmits a live migration instruction to each of the migration source VM host and the migration destination VM host.
  • FIG. 25 is a diagram illustrating an example of a TOP screen
  • FIG. 26 is a diagram illustrating a screen example in which a migration target VM guest list is displayed
  • FIG. 27 is a diagram in which a migration destination candidate VM host list is displayed. It is a figure which shows the example of a screen.
  • FIG. 28 is a diagram showing an example of a screen in which one VM host is selected as a migration destination candidate
  • FIG. 29 is a diagram showing a screen example in which a migration destination VM host is determined
  • FIG. It is a figure which shows the example of a screen in which the classification was determined.
  • FIG. 31 is a diagram showing an example of a screen in which another migration source VM host has been selected in a state where the migration of another VM guest has already been determined
  • FIG. 32 shows the migration target VM guest from the state of FIG. It is a figure which shows the example of the selected screen.
  • FIG. 33 is a diagram illustrating a screen example in which a migration destination candidate VM host is selected from the state of FIG. 32
  • FIG. 34 is a diagram illustrating a screen example in which the migration destination VM host is determined from the state of FIG.
  • FIG. 35 is a diagram showing an example of a screen in which the movement type is determined from the state of FIG.
  • FIG. 36 is a diagram illustrating a screen example for further determining the migration destination of another VM guest from the state of FIG. 35.
  • FIG. 37 is a screen in which a migration target VM guest is selected from the state of FIG. It is a figure which shows an example.
  • FIG. 38 is a diagram illustrating an example of a screen in which another VM guest has already been decided to be migrated to the VM host selected as the migration destination candidate.
  • FIG. 39 is a diagram illustrating a screen example in which the migration type is determined from the state of FIG. 38
  • FIG. 40 is a diagram illustrating a screen example in which it is determined that a plurality of VM guests are migrated to one VM host. is there.
  • the VM host generation unit 35 of the mobility management device 30 displays the TOP screen shown in FIG. Send to. Specifically, the VM host generation unit 35 transmits a screen in which the VM host name (NAME) acquired from the VM host table 34 b or the like is displayed in the “Source VM Host List” field to the client device 10.
  • NAME VM host name
  • the VM host generation unit 35 displays “Host_a”, “Host_b”, and “Host_c”.
  • the VM guest candidate generation unit 36 determines the migration source VM host as “Host_b”. Subsequently, the VM guest candidate generation unit 36 refers to each table and extracts “Guest_b1”, “Guest_b2”, and “Guest_b3” as VM guests operating in “Host_b”. Then, the VM guest candidate generation unit 36 transmits a screen in which “Guest_b1”, “Guest_b2”, and “Guest_b3” are displayed in the “Source VM Guest List” field to the client device 10 as illustrated in FIG.
  • the migration destination candidate generation unit 37 refers to each table and uses the same or the same VM management software as the migration source VM host “Host_b” Identify other VM hosts that run. Subsequently, as illustrated in FIG. 27, the migration destination candidate generation unit 37 displays a screen in which “Host_f” and “Host_g” are displayed in the “Target VM Host List” field as the migration destination candidate VM host. Send to.
  • the movement determination unit 38 determines whether or not the migration target VM guest “Guest_b2” can be moved to “Host_g”. Judgment by.
  • the movement type determination unit 39 transmits a screen in which the field is activated based on the power state of the movement target VM guest “Guest_b2” to the client device 10.
  • the migration type determination unit 39 identifies from the VM guest table 34e that the power state of the VM guest “Guest_b2” is “OFF”. Then, as shown in FIG. 29, the movement type determination unit 39 transmits a screen in which the “Cold Migration” field is activated to the client device 10. Thereafter, as illustrated in FIG. 30, the migration type determination unit 39 transmits a screen in which “Guest_b2” whose VM guest power state is “OFF” is displayed in the “Cold Migration” field to the client device 10.
  • the VM guest candidate creation unit 36 determines the migration source VM host as “Host_c”. Subsequently, the VM guest candidate generation unit 36 refers to each table and extracts “Guest_c1” and “Guest_c3” as VM guests operating in “Host_c”. Then, as illustrated in FIG. 31, the VM guest candidate generation unit 36 transmits a screen in which “Guest_c1” and “Guest_c3” are displayed in the “Source VM Guest List” field to the client device 10.
  • the migration destination candidate generation unit 37 refers to each table and manages the same or the same VM management as the migration source VM host “Host_c”. Specify another VM host that runs the software. Subsequently, as shown in FIG. 32, the migration destination candidate generation unit 37 displays a screen in which “Host_a”, “Host_d”, and “Host_e” are displayed in the “Target VM Host List” field as migration destination candidate VM hosts. It transmits to the client device 10.
  • the movement determination unit 38 determines whether or not the migration target VM guest “Guest_c1” can be moved to “Host_a”. Judgment by.
  • the movement type determination unit 39 transmits a screen in which the field is activated based on the power state of the movement target VM guest “Guest_c1” to the client device 10.
  • the migration type determination unit 39 specifies from the VM guest table 34e that the power state of the VM guest “Guest_c1” is “ON”. Then, as shown in FIG. 34, the movement type determination unit 39 transmits a screen in a state where the “Cold Migration” field and the “Live Migration” field are activated to the client device 10.
  • the migration type determination unit 39 displays a screen displaying “Guest_c1” in the “Live Migration” field because the power state of the VM guest “Guest_c1” is “ON”. 10 to send. That is, in the state up to this point, it is determined that the mobility management device 30 moves “Guest_b2” operating on the VM host “Host_b” to “Host_g” by “cold migration”. Furthermore, it is determined that the migration management apparatus 30 moves “Guest_c1” operating on the VM host “Host_c” to “Host_a” by “live migration”.
  • the VM guest candidate creation unit 36 selects the migration source VM host. Determine “Host_b”. Subsequently, the VM guest candidate generation unit 36 refers to each table and extracts “Guest_b1” and “Guest_b3” as VM guests operating in “Host_b”. Then, the VM guest candidate generation unit 36 transmits a screen in which “Guest_b1” and “Guest_b3” are displayed in the “Source VM Guest List” field to the client device 10 as illustrated in FIG.
  • the client device 10 selects “Guest_b3”.
  • the VM guest candidate creation unit 36 excludes “Guest_b2” from the migration target even if “Host_b” is selected as the migration source because the migration destination has already been determined.
  • the migration destination candidate generation unit 37 refers to each table and operates other VM management software of the same type or the same as the migration source VM host “Host_b”. Identify the VM host. That is, as shown in FIG. 37, the migration destination candidate generation unit 37 displays a screen in which “Host_f” and “Host_g” are displayed in the “Target VM Host List” field as the migration destination candidate VM host on the client device 10. Send.
  • the movement determination unit 38 determines whether or not the migration target VM guest “Guest_b3” can be moved to “Host_g”. Judgment by.
  • the movement determination unit 38 displays “Guest_b2” in the “Cole Migration” field when “Host_g” is selected by the client device 10.
  • the transmitted screen is transmitted to the client device 10.
  • the movement determination unit 38 determines whether or not both can be moved since “Host_g” is selected as a new movement destination candidate of “Guest_b3” in a state where “Host_g” is determined as the movement destination of “Guest_b2”. judge. Note that the determination method is omitted because it has been described in the configuration and the like.
  • the movement determination unit 38 does not specify the power state of “Guest_b3” in the state of FIG. 38, so that the “Cold Migration” field and the “Live Migration” field are deactivated, “Guest_b2” is displayed in the “Migration” field.
  • the movement type determination unit 39 transmits a screen in which the field is activated based on the power state of the movement target VM guest “Guest_b3” to the client device 10.
  • the migration type determination unit 39 activates the “Cold Migration” field and the “Live Migration” field as shown in FIG. The converted screen is transmitted to the client device 10.
  • the migration type determination unit 39 displays a screen in which “Guest_b3” is displayed in the “Live Migration” field because the power state of the VM guest “Guest_b3” is “ON”. 10 to send. That is, in the state up to this point, it is determined that the mobility management device 30 moves “Guest_b2” operating on the VM host “Host_b” to “Host_g” by “cold migration”. Furthermore, it is determined that the migration management apparatus 30 moves “Guest_c1” operating on the VM host “Host_c” to “Host_a” by “live migration”. Furthermore, it is determined that the migration management apparatus 30 moves “Guest_b3” operating on the VM host “Host_b” to “Host_g” by “live migration”.
  • the migration instruction unit 40 performs migration of the VM guest whose migration destination and migration type are determined. .
  • the migration instruction unit 40 refers to the migration_lists variable, and transmits a migration start instruction for each VM guest displayed in the “Cold Migration” field and the “Live Migration” field to the VM management apparatus. Then, the VM management apparatus transmits a migration instruction to each of the migration source VM host and the migration destination VM host. As a result, each VM host can execute migration for the instructed VM guest.
  • any VM guest can be moved to a plurality of VM hosts without being aware of the load on the VM host or the VM management apparatus. Since the movement management device 30 transmits the contents of the processing related to the migration of the VM guest to the client device on the Web screen, the user can perform a plurality of movement settings with a simple operation.
  • the migration management apparatus 30 can execute the migration instruction of the VM guest at once, the administrator can reduce the binding time required for executing the migration process of the VM guest such as migration setting and confirmation of normal termination after the migration is performed. can do. As a result, the manager can improve work efficiency. Also, the entire migration processing time can be shortened and the load on the server can be reduced by moving VM guests one by one.
  • the mobility management device 30 may be displayed on the display unit 33 included in the device itself and receive a user operation from a screen displayed on the display unit 33.
  • the movement management device 30 can accept a user's selection by accepting a drag-and-drop on an icon for a movement type result or the like.
  • the migration management apparatus 30 can determine the migration destination VM host and the migration type using the information in each table without generating a Web screen and inquiring the user. That is, the migration management apparatus 30 identifies each VM guest that is a migration target from each table. Then, for each VM guest, the migration management apparatus 30 simulates the migration of the VM guest and determines the migration destination. Furthermore, the migration management apparatus 30 determines the migration method of the VM guest based on the power state of the VM guest whose migration destination has been determined. Thereafter, when the migration destination and the migration method are determined for each VM guest that is the migration target, the migration management apparatus 30 moves each VM guest to the determined migration destination using the determined migration method.
  • the mobility management device 30 can automatically execute all the processes using each table. Further, the movement management device 30 may generate only a part of the process described in the second embodiment or the like as a movement type determination result as a Web screen. That is, the mobility management device 30 can not only automatically determine the migration type and the like, but can also accept designation from the user from a screen displayed on the client device 10 or the like. In this case, the mobility management device 30 may prioritize automatic determination or prioritize user designation according to an instruction or setting by an administrator or the like.
  • the present invention is not limited to this.
  • migration destination host or the like is designated by an administrator or the like, migration can be executed to another migration destination after performing migration to the designated migration destination host. Therefore, the setting can be arbitrarily changed in consideration of the load status of the migration destination host and the migration source host, the load status of the VM management apparatus, the network usage rate, and the like.
  • each component of each illustrated apparatus is functionally conceptual and does not necessarily need to be physically configured as illustrated. That is, the specific form of distribution / integration of each device, for example, integrating the movement determination unit 38 and the movement type determination unit 39 is not limited to that shown in the figure. That is, all or a part of them can be configured to be functionally or physically distributed / integrated in arbitrary units according to various loads or usage conditions. Further, all or any part of each processing function performed in each device may be realized by a CPU and a program analyzed and executed by the CPU, or may be realized as hardware by wired logic.
  • program By the way, the various processes described in the above embodiments can be realized by executing a program prepared in advance on a computer system such as a personal computer or a workstation. Therefore, in the following, an example of a computer system that executes a program having the same function as in the above embodiment will be described.
  • FIG. 41 is a diagram illustrating an example of a computer that executes a mobility management program.
  • the computer 100 includes a RAM 101, an HDD 102, a ROM 103, a CPU 104, and a recording medium reading device 105.
  • the HDD 102 is provided with tables having the same functions as the tables 34a to 34g shown in FIG. That is, the HDD 102 includes a variable management table 102a, a VM host table 102b, a VM table 102c, a VM guest table 102d, a server profile table 102e, a VM management table 102f, and a management software table 102g.
  • the ROM 103 stores in advance a program that exhibits the same function as in the above embodiment. That is, as shown in FIG. 41, the ROM 103 stores a movement management program 103a in advance.
  • the CPU 104 reads and executes the movement management program 103a, thereby executing the movement management process 104a as shown in FIG.
  • the movement management process 104a performs the same operation as each control unit shown in FIG. That is, the movement management process 104a executes the same operations as the VM host generation unit 35, the VM guest candidate generation unit 36, the movement destination candidate generation unit 37, the movement determination unit 38, the movement type determination unit 39, and the movement instruction unit 40. .
  • the above-described mobility management program 103 a is not necessarily stored in the ROM 103.
  • it may be stored in a “portable physical medium” such as a flexible disk (FD), a CD-ROM, a DVD disk, a magneto-optical disk, or an IC card inserted into the computer 100.
  • a “fixed physical medium” such as a hard disk drive (HDD) provided inside or outside the computer 100.
  • HDD hard disk drive
  • it may be stored in “another computer” connected to the computer 100 via a public line, the Internet, a LAN, a WAN, or the like. Then, the computer 100 may read and execute the program from these.
  • the program referred to in the other embodiments is recorded in a computer-readable manner on a recording medium such as the above-mentioned “portable physical medium”, “fixed physical medium”, “communication medium”, and the like.
  • the computer 100 can realize the same function as the above-described embodiment by reading the movement management program from the recording medium by the recording medium reading device 105 and executing the read movement management program.
  • the program referred to in the other embodiments is not limited to being executed by the computer 100.
  • the present invention can be similarly applied to a case where another computer or server executes the program, or a case where these programs cooperate to execute the program.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Debugging And Monitoring (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

　移動管理装置は、移動対象であるＶＭゲスト各々について、当該ＶＭゲストの移動をシミュレーションして、移動先のＶＭホストを決定する。続いて、移動管理装置は、移動先のＶＭホストが決定されたＶＭゲストの電源状態に基づいて、当該ＶＭゲストの移動方式を決定する。その後、移動管理装置は、移動対象であるＶＭゲスト各々について移動先および移動方式が決定された場合に、決定された移動先に、決定された移動方式で、ＶＭゲスト各々を一括で移動させる。

Description

移動管理装置、移動管理方法および移動管理プログラム
　本発明は、移動管理装置、移動管理方法および移動管理プログラムに関する。
　従来、大規模データセンタ等の分散コンピュータシステムのような大規模システムでは、処理を担当するハーウェアを交代させる、すなわち処理を異なるハードウェアに移動させることで、システムの可用性を高めている。一例として、ハードウェア上でＶＭ（Virtual　Machine）ホストを動作させ、このＶＭホスト上でＶＭゲストを動作させる技術が知られている。
　ＶＭホストは、コンピュータシステムの動作環境を仮想的に実現するプログラムである。ＶＭゲストは、ＶＭホストによって提供された環境で仮想マシンとして動作し、ユーザに提供される処理を担う。このＶＭゲストは、異なるＶＭホストに移動しても処理を継続することができる。
　このように、ＶＭゲストを異なるＶＭホストに移動させる技術として、ＶＭゲストの稼動を停止させることなく移動させるライブマイグレーションやＶＭゲストの稼動を停止してから移動させるコールドマイグレーションなどのマイグレーションが利用されている。なお、ＶＭゲストに限らず、ＶＭホストを他の物理サーバに移動させる場合にも、マイグレーションが利用されている。
　例えば、従来では、ＧＵＩ（Graphical　User　Interface）、ＣＬＩ（Command　line　interface）、Ｓｃｒｉｐｔなどを用いて、移動対象のＶＭゲストを１台ずつ、移動先ＶＭホストを指定して移動させる技術が利用されている。
　近年では、自動でマイグレーションを実行する技術も知られている。例えば、ＶＭゲストの移動先対象となる各サーバのＣＰＵ使用率、メモリ使用量、移動にかかる時間に基づいて、当該ＶＭゲストが移動できるサーバ上の仮想化ソフトウェアを特定する。そして、特定した仮想化ソフトウェア上に、移動対象のＶＭゲストをライブマイグレーションする技術が知られている。
　また、ＶＭホストやＶＭゲストを稼動させる仮想マシンシステムの負荷のサイクルに基づいてスケジューリングし、スケジューリングに従ってライブマイグレーションを自動実行する技術も知られている。
特開２００８－２１７３０２号公報 特開２０１０－１１７７６０号公報 特表２００７－５３６６５７号公報
　しかしながら、従来の技術では、複数の仮想マシンが移動対象である場合に、仮想マシンを１つ１つ移動させたり、仮想マシン１つ１つの移動完了を確認したりするので、仮想マシンの移動処理を管理する管理者の作業が煩雑になり、管理者を拘束する時間が長いという問題がある。
　例えば、ＧＵＩやコマンド等を用いる技術では、移動対象のＶＭゲスト１台ずつに対して、移動先ＶＭホストの指定およびライブマイグレーションの実行をして、ライブマイグレーションが正常に終了したかを確認することになる。つまり、連続してライブマイグレーションを実行できない。このため、全てのＶＭゲストの移動が正常に完了するまで、管理者を拘束することになる。
　また、スケジュール等に従ってライブマイグレーションを自動化する場合、移動対象のＶＭゲストが停止中である場合には、ライブマイグレーションが異常終了する。この結果、移動させたいＶＭゲストが移動できないまま処理が終了する場合もある。つまり、自動で実行する場合も、自動で実行された後に管理者が正常終了を確認することになるので、結果として、実行後から正常終了確認まで管理者を拘束することになる。したがって、この技術を用いた場合でも、管理者の作業時間は短くない。
　１側面では、本発明は、仮想マシンの移動処理の作業時間を短縮することができる移動管理装置、移動管理方法および移動管理プログラムを提供することを目的とする。
　第１の案では、移動管理装置は、移動対象である仮想マシン各々について、当該仮想マシンの移動をシミュレーションして、移動先を決定する第１決定部を有する。移動管理装置は、前記第１決定部によって移動先が決定された仮想マシンの電源状態に基づいて、当該仮想マシンの移動方式を決定する第２決定部を有する。移動管理装置は、前記移動対象である仮想マシン各々について移動先および移動方式が決定された場合に、前記第１決定部によって決定された移動先に、前記第２決定部によって決定された移動方式で、前記仮想マシン各々を移動させる移動処理部を有する。
　仮想マシンの移動処理の作業時間を短縮することができる。
図１は、実施例１に係る移動管理装置を含むシステムの全体構成を示す図である。 図２は、実施例２に係る移動管理装置を含むシステムを形成する各装置の構成を示すブロック図である。 図３は、変数管理テーブルが記憶するsrc＿vm＿hosts変数の例を示す図である。 図４は、変数管理テーブルが記憶するsrc＿vm＿guests変数の例を示す図である。 図５は、変数管理テーブルが記憶するdst＿vm＿hosts変数の例を示す図である。 図６は、変数管理テーブルが記憶するmigration＿lists変数の例を示す図である。 図７は、ＶＭホストテーブルに記憶される情報の例を示す図である。 図８は、ＶＭテーブルに記憶される情報の例を示す図である。 図９は、ＶＭゲストテーブルに記憶される情報の例を示す図である。 図１０は、サーバプロファイルテーブルに記憶される情報の例を示す図である。 図１１は、ＶＭ管理テーブルに記憶される情報の例を示す図である。 図１２は、管理ソフトテーブルに記憶される情報の例を示す図である。 図１３は、マイグレーション処理のＴＯＰ画面例を示す図である。 図１４は、移動管理装置が実行する処理の全体的な流れを説明するフローチャートである。 図１５は、ＶＭゲスト候補生成処理の流れを説明するフローチャートである。 図１６は、移動先候補のＶＭホストリスト生成処理の流れを説明するフローチャートである。 図１７は、移動可能判定処理の流れを説明するフローチャートである。 図１８は、移動種別決定処理の流れを説明するフローチャートである。 図１９は、ＴＯＰ画面例を示す図である。 図２０は、移動対象のＶＭゲスト一覧を表示させた画面例を示す図である。 図２１は、移動先候補のＶＭホスト一覧を表示させた画面例を示す図である。 図２２は、移動先候補として１つのＶＭホストが選択された画面例を示す図である。 図２３は、移動先のＶＭホストが決定された画面例を示す図である。 図２４は、移動種別が決定された画面例を示す図である。 図２５は、ＴＯＰ画面例を示す図である。 図２６は、移動対象のＶＭゲスト一覧を表示させた画面例を示す図である。 図２７は、移動先候補のＶＭホスト一覧を表示させた画面例を示す図である。 図２８は、移動先候補として１つのＶＭホストが選択された画面例を示す図である。 図２９は、移動先のＶＭホストが決定された画面例を示す図である。 図３０は、移動種別が決定された画面例を示す図である。 図３１は、既に他のＶＭゲストの移動が決定された状態で別の移動元ＶＭホストが選択された画面例を示す図である。 図３２は、図３１の状態から移動対象のＶＭゲストが選択された画面例を示す図である。 図３３は、図３２の状態から移動先候補のＶＭホストが選択された画面例を示す図である。 図３４は、図３３の状態から移動先のＶＭホストが決定した画面例を示す図である。 図３５は、図３４の状態から移動種別が決定された画面例を示す図である。 図３６は、図３５の状態からさらに続けて他のＶＭゲストの移動先を決定する画面例を示す図である。 図３７は、図３６の状態から移動先対象のＶＭゲストが選択された画面例を示す図である。 図３８は、移動先候補として選択されたＶＭホストに既に別のＶＭゲストの移動が決定されている画面例を示す図である。 図３９は、図３８の状態から移動種別が決定された画面例を示す図である。 図４０は、１つのＶＭホストに複数のＶＭゲストが移動することが決定された画面例を示す図である。 図４１は、移動管理プログラムを実行するコンピュータの例を示す図である。
　以下に、本発明にかかる移動管理装置、移動管理方法および移動管理プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
　図１は、実施例１に係る移動管理装置を含むシステムの全体構成を示す図である。図１に示すように、このシステムは、クライアント装置１０と、移動管理装置３０と、ＶＭ（Virtual　Machine）管理装置５０と、ＶＭ管理装置７０と、複数のサーバ（ＶＭホスト）６０とを有する。なお、図１に示したサーバの台数や装置の台数は、あくまで例示であり、これに限定されるものではなく、任意の台数を設定することができる。
　クライアント装置１０は、このシステムの管理者やユーザが利用するコンピュータであり、ＶＭゲストの移動指示を移動管理装置３０に送信して、ＶＭゲストのマイグレーションを実行させる。
　移動管理装置３０は、第１決定部３０ａ、第２決定部３０ｂ、移動処理部３０ｃを有し、クライアント装置１０からＶＭゲストのマイグレーション指示を受信して、ＶＭ管理装置５０やＶＭ管理装置７０に、ＶＭゲストのマイグレーションの実行を要求する。
　ＶＭ管理装置５０やＶＭ管理装置７０は、物理サーバ上で動作しているＶＭホストや、ＶＭホスト上で動作しているＶＭゲストに関する情報等を記憶して、仮想マシン全体を管理するサーバである。例えば、ＶＭ管理装置５０やＶＭ管理装置７０は、ＶＭホストやＶＭゲストのリソース状況や、ＶＭホスト上で動作可能なＶＭゲストの最大数などＶＭホストに関する情報を記憶する。
　サーバ６０は、仮想マシンであるＶＭゲストを動作させる、他のコンピュータシステムの動作環境を仮想的に実現するプログラムであるＶＭホストを実行する物理サーバである。ＶＭゲストは、ＶＭホストによって提供された環境でユーザに提供される処理を担う仮想マシンである。
　このような状況において、移動管理装置３０の第１決定部３０ａは、移動対象であるＶＭゲスト各々について、当該ＶＭゲストの移動をシミュレーションして、移動先のＶＭホストを決定する。続いて、第２決定部３０ｂは、移動先のＶＭホストが決定されたＶＭゲストの電源状態に基づいて、当該ＶＭゲストの移動方式を決定する。その後、移動処理部３０ｃ、移動対象であるＶＭゲスト各々について移動先および移動方式が決定された場合に、第１決定部３０ａが決定した移動先に、第２決定部３０ｂが決定した移動方式で、ＶＭゲスト各々を一括で移動させる。
　このように、ＶＭゲストの移動先候補として特定されたＶＭホストに、実際に移動可能か否かをシミュレーションする。そして、移動可能である場合に、ＶＭゲストの電源状態に応じた移動方式で実際に移動させる。この結果、ＶＭゲストが移動できるＶＭホストを特定し、特定したＶＭホストに、ＶＭゲストに適した移動方式で実行させることができる。したがって、各ＶＭゲストについて、移動可能なことを判定して適切な移動方式で一括で移動させることができるので、各ＶＭゲストのマイグレーションの正常終了を確認する手間も省ける。この結果、ＶＭゲストを１つずつ移動させるより、ＶＭゲストの移動処理を管理する管理者の作業時間を短縮することができる。
　次に、実施例２に係る移動管理装置について説明する。ここでは、図１に示したシステムにおける各装置の構成、処理の流れ、実施例２による効果を説明する。
［システムの構成］
　図２は、実施例２に係る移動管理装置を含むシステムを形成する各装置の構成を示すブロック図である。なお、ＶＭ管理装置５０とＶＭ管理装置７０とは同様の構成を有するので、ここでは、ＶＭ管理装置５０を例にして説明する。同様に、図１に示した各サーバは同様の構成を有するので、ここでは、サーバ６０を例にして説明する。
（移動管理装置の構成）
　図２に示すように、移動管理装置３０は、通信制御Ｉ／Ｆ部３１と、入力部３２と、表示部３３と、記憶部３４と、各制御部とを有する。なお、各制御部は、例えばＣＰＵなどの電子回路であり、ＶＭホスト生成部３５、ＶＭゲスト候補生成部３６、移動先候補生成部３７、移動判定部３８、移動種別決定部３９、移動指示部４０を有する。
　通信制御Ｉ／Ｆ部３１は、少なくとも１つのポートを有し、他の装置との通信を制御するインタフェースである。例えば、通信制御Ｉ／Ｆ部３１は、クライアント装置１０と接続され、ＶＭゲストのマイグレーション処理の開始指示を受信して、各制御部に出力する。また、通信制御Ｉ／Ｆ部３１は、ＶＭ管理装置５０やＶＭ管理装置７０と接続され、ＶＭ管理装置５０やＶＭ管理装置７０に、移動指示部４０から指示されたＶＭゲストのマイグレーション指示を送信する。また、通信制御Ｉ／Ｆ部３１は、ＶＭ管理装置５０やＶＭ管理装置７０からマイグレーション結果を受信する。また、通信制御Ｉ／Ｆ部３１は、各制御部が生成したＷｅｂ画面をクライアント装置１０に送信する。
　入力部３２は、例えばキーボードやマウスなどの入力装置であり、表示部３３と協働してポインティングディバイス機能を実現し、表示部３３に表示される入力画面や選択画面への入力を受け付けて、表示部３３や各制御部に出力する。一例を挙げると、入力部３２は、移動対象のＶＭホストやＶＭゲストの選択、移動種別の選択などを受け付ける。表示部３３は、例えばディスプレイなどの表示装置であり、各制御部によって生成されたＷｅｂ画面などを表示する。
　記憶部３４は、例えば半導体メモリ素子やハードディスクなどの記憶装置である。この記憶部３４は、変数管理テーブル３４ａと、ＶＭホストテーブル３４ｂと、ＶＭテーブル３４ｃと、ＶＭゲストテーブル３４ｄと、サーバプロファイルテーブル３４ｅと、ＶＭ管理テーブル３４ｆと、管理ソフトテーブル３４ｇとを有する。なお、各テーブルの説明で例示する情報は、あくまで例示であり、これに限定されるものではなく、任意に設定変更できる。また、各テーブルに記憶される情報は、管理者等によって更新されてもよく、ＶＭ管理装置３０によって定期的に更新されてもよい。
　変数管理テーブル３４ａは、各制御部が処理を実行する際に用いる変数を記憶する。例えば、変数管理テーブル３４ａは、src＿vm＿hosts変数、src＿vm＿guests変数、dst＿vm＿hosts変数、migration＿lists変数を記憶する。なお、図３から図６に示した情報は、例えばホスト名ではなくＩＰ（Internet　Protocol）アドレスやＭＡＣ（Media　Access　Control）アドレスなど、任意に変更可能である。
　src＿vm＿hosts変数は、ＶＭホスト生成部３５等が移動元のＶＭホストを表示するＷｅｂ画面を生成する際に使用される。図３は、変数管理テーブルが記憶するsrc＿vm＿hosts変数の例を示す図である。図３に示すように、変数管理テーブル３４ａは、src＿vm＿hosts変数として「array＿index、ID、NAME」を記憶する。ここで記憶される「array＿index」は、格納する配列の位置を識別する識別子であり、「ID」は、ＶＭホストを区別するために用いる識別子であり、「NAME」は、移動元のＶＭホストのホスト名である。
　図３の例で説明すると、「array＿index＝0、ID＝1、NAME＝Host＿a」の場合、src＿vm＿hosts変数の配列「0」には、ID「1」が割り与えられた「Host＿a」のホスト名を有するＶＭホストに関する情報が格納されていることを示す。また、「array＿index＝7、ID＝8、NAME＝Host＿h」の場合には、src＿vm＿hosts変数の配列「7」には、ID「8」が割り与えられた「Host＿h」のホスト名を有するＶＭホストに関する情報が格納されていることを示す。
　src＿vm＿guests変数は、ＶＭゲスト候補生成部３６等が移動対象となるＶＭゲストを表示するＷｅｂ画面を生成する際に使用される。図４は、変数管理テーブルが記憶するsrc＿vm＿guests変数の例を示す図である。なお、図４のｓ１は、移動候補のＶＭゲスト一覧を示しており、図４のｓ２は、ｓ１の状態から「Guest＿c1」が移動対象として決定された後の状態を示している。図４に示すように、変数管理テーブル３４ａは、src＿vm＿guests変数として「Hash＿key、array＿index、ID、NAME」を記憶する。ここで記憶される「Hash＿key」は、「NAME」に格納されるＶＭゲストが動作するＶＭホストを識別する識別子であり、「array＿index」は、格納位置を識別する識別子である。また、「ID」は、ＶＭゲストを区別するために用いる識別子であり、「NAME」は、移動候補のＶＭゲストの名称である。
　図４のｓ１に例示した「Hash＿key＝2、array＿index＝2、ID＝23、NAME＝Guest＿b3」の場合について説明する。この場合、Hash＿keyが「2」で識別されるＶＭホストが対応付けられた配列「2」には、ID「23」が割り与えられた移動対象候補であるＶＭゲスト「Guest＿b3」が格納されることを示す。また、「Hash＿key＝3、array＿index＝1、ID＝27、NAME＝Guest＿c3」の場合について説明する。この場合、Hash＿keyが「3」で識別されるＶＭホストが対応付けられた配列「1」には、ID「27」が割り与えられた移動対象候補のＶＭゲスト「Guest＿c3」が格納されることを示す。また、図４のｓ１の状態で「NAME＝Guest＿c3」が移動先対象として特定された場合には、図４のｓ２に示すように、「Hash＿key＝3、array＿index＝1、ID＝27、NAME＝Guest＿c3」のレコードが削除される。
　dst＿vm＿hosts変数は、移動先候補生成部３７等が移動先候補のＶＭホストを表示するＷｅｂ画面を生成する際に使用される。図５は、変数管理テーブルが記憶するdst＿vm＿hosts変数の例を示す図である。なお、図５のｓ３は、移動先候補のＶＭホスト一覧を示しており、図５のｓ４は、ｓ３の状態から「Guest＿b2」が移動対象として決定された後の移動先候補となるＶＭホスト一覧を示している。図５に示すように、変数管理テーブル３４ａは、dst＿vm＿hosts変数として「Hash＿key、array＿index、ID、NAME」を記憶する。ここで記憶される「Hash＿key」は、移動元となるホストを識別する識別子であり、「array＿index」は、格納位置を識別する識別子である。また、「ID」は、移動先候補のＶＭホストを区別するために用いる識別子であり、「NAME」は、移動先候補のＶＭホストのホスト名である。
　図５のｓ３に例示した「Hash＿key＝3、array＿index＝0、ID＝1、NAME＝Host＿a」の場合について説明する。この場合、Hash＿keyが「3」である移動元のＶＭホストに対応付けられた配列「0」には、移動先候補のＶＭホストとして、ID「1」が割り与えられた「Host＿a」が格納されることを示す。また、図５のｓ３の状態で、ＶＭゲスト「Guest＿b2」が移動対象として決定された場合、図５のｓ４に示すように、「Hash＿key＝2、array＿index＝0、ID＝6、NAME＝Host＿f」と「Hash＿key＝2、array＿index＝1、ID＝7、NAME＝Host＿g」が追加される。つまり、移動先候補生成部３７は、移動対象として決定されたＶＭゲスト「Guest＿b2」の移動先候補として、ＶＭホスト「Host＿f」と「Host＿g」をdst＿vm＿hosts変数に追加する。
　migration＿lists変数は、移動判定部３８等が移動対象のＶＭゲストのマイグレーション手法を決定する場合や、移動指示部４０が移動指示を送信する場合に用いられる。図６は、変数管理テーブルが記憶するmigration＿lists変数の例を示す図である。図６に示すように、変数管理テーブル３４ａは、migration＿lists変数として「Hash＿key、array＿index、ID、migration＿type」を記憶する。ここで記憶される「Hash＿key」は、移動先となるＶＭホストを識別する識別子であり、「array＿index」は、格納位置を識別する識別子である。また、「ID」は、ＶＭゲストを区別するために用いる識別子であり、「migration＿type」は、マイグレーションの手法を示す情報である。
　図６の例で説明すると、「Hash＿key＝7」であるＶＭホストを移動先として配列「0」に格納される「ID＝22」のＶＭゲストは、コールドマイグレーションで移動されることを示す。また、「Hash＿key＝7」であるＶＭホストを移動先として配列「1」に格納される「ID＝23」のＶＭゲストは、ライブマイグレーションで移動されることを示す。また、「Hash＿key＝1」であるＶＭホストを移動先として配列「0」に格納される「ID＝25」のＶＭゲストは、ライブマイグレーションで移動されることを示す。
　図２に戻り、ＶＭホストテーブル３４ｂは、移動管理装置３０が管理するＶＭホストの一覧を記憶する。図７は、ＶＭホストテーブル３４ｂに記憶される情報の例を示す図である。図７に示すように、ＶＭホストテーブル３４ｂは、ＶＭホストの情報として、「ID、NAME、api＿type、virtual＿machines、logical＿server＿id（SV）」を対応付けて記憶する。なお、ここで記憶される情報は、管理者等によって手動やジョブなどよって随時更新されてもよく、移動管理装置３０が各ＶＭ管理装置から定期的に取得するようにしてもよい。
　ここで記憶される「ID」は、ＶＭホストテーブル３４ｂに記憶される情報を識別する識別子であり、「NAME」は、ＶＭホストのホスト名などである。「api＿type」は、ＶＭホストを実現してＶＭゲストを動作させるＡＰＩ（Application　Programming　Interface）の種別を示す。「virtual＿machines」は、動作するＶＭゲストを示す情報であり、配列で格納される。「logical＿server＿id（SV）」は、後述するサーバプロファイルテーブルのレコードを特定する識別子である。
　図７の例の場合、「ID＝2」には、「API（B）」上でＶＭゲスト「ＶＭ１０１～ＶＭ１０４」を実行するＶＭホスト「Host＿b」の情報が記憶されており、この「Host＿b」の情報には、「logical＿server＿id（SV）＝2」が対応付けられている。また、「ID＝3」には、「API（A）」上でＶＭゲスト「ＶＭ１０５～ＶＭ１０７」を実行するＶＭホスト「Host＿c」の情報が記憶されており、この「Host＿c」の情報には、「logical＿server＿id（SV）＝3」が対応付けられている。なお、図７に記載される「省略」は、説明上、記載を省略したことを示しており、例えばＶＭ２０１～ＶＭ２０３などの情報が格納される。
　ＶＭテーブル３４ｃは、ＶＭホスト上で仮想マシンとして動作しているＶＭゲストに関する詳細な情報を記憶する。図８は、ＶＭテーブルに記憶される情報の例を示す図である。図８に示すように、ＶＭテーブル３４ｃは、ＶＭゲストに関する詳細な情報として「ID、os＿instance、power＿status、vm＿host＿id、メモリ容量、CPU数、CPUスペック」を対応付けて記憶する。
　ここで記憶される「ID」は、ＶＭテーブル３４ｃの各レコードを識別する識別子であり、「os＿instance」は、ＶＭゲストオブジェクトのリンク先を示す情報であり、仮想マシンとして動作するＶＭゲストを特定する情報である。「power＿status」は、仮想マシン言い換えるとＶＭゲストの電源状態を示しており、電源がオンの場合には「ON」、電源がオフの場合には「OFF」、電源状態が検出できなかった場合には「unknown」が格納される。「vm＿host＿id」は、ＶＭゲストが動作するＶＭホストを特定する情報であり、ＶＭホストテーブル３４ｂのIDが格納される。「メモリ容量」は、ＶＭゲストに割り与えられたメモリ容量であり、「CPU数」は、ＶＭゲストに割り与えられたCPUの数である。「CPUスペック」は、ＶＭゲストに割り与えられたCPUの性能を示す情報であり、ここでは、CPUのクロック周波数が格納される例を示す。
　図８の例の場合、IDが「101」であるレコードは、「vm＿host＿id＝2」が割り与えられたＶＭホスト上で、メモリ容量が1GBであり、1.2GHｚのCPU2つが割り与えられたＶＭゲスト「Guest＿b1」が動作していることを示す。また、IDが「102」であるレコードは、「vm＿host＿id＝2」が割り与えられたＶＭホスト上で、メモリ容量が750MBであり、3GHｚのCPU2つが割り与えられたＶＭゲスト「Guest＿b2」が停止中であることを示す。また、IDが「106」であるレコードは、「vm＿host＿id＝3」が割り与えられたＶＭホスト上で、メモリ容量が1GBであり、2GHｚのCPU3つが割り与えられたＶＭゲスト「Guest＿c2」が存在するが、電源状態が検出できない状態であることを示す。
　ＶＭゲストテーブル３４ｄは、ＶＭゲストに関する情報を記憶する。図９は、ＶＭゲストテーブルに記憶される情報の例を示す図である。図９に示すように、ＶＭゲストテーブル３４ｄは、ＶＭゲストに関する情報として「ID、NAME、logical＿server＿id（VM）」を対応付けて記憶する。ここで記憶される「ID」は、ＶＭゲストを一意に識別する識別子であり、「NAME」は、ＶＭゲストの示す名称である。「logical＿server＿id（VM）」は、ＶＭホストを特定する際に使用される識別子であり、ＶＭテーブル３４ｃに記憶される「ID」が格納される。
　図９の例の場合、IDが「21」であるＶＭゲスト「Guest＿b1」に関する情報は、ＶＭテーブル３４ｃのIが「101」であるレコードに対応することが示されている。同様に、IDが「25」であるＶＭゲスト「Guest＿c1」に関する情報は、ＶＭテーブル３４ｃのIDが「105」であるレコードに対応することが示されている。
　サーバプロファイルテーブル３４ｅは、ＶＭホストごとに、当該ＶＭホストで利用可能なＶＭ管理ソフトに関する情報を記憶する。図１０は、サーバプロファイルテーブル３４ｅに記憶される情報の例を示す図である。図１０に示すように、サーバプロファイルテーブル３４ｅは、ＶＭホストの情報として「ID、os＿instance、vm＿managings」を対応付けて記憶する。
　ここで記憶される「ID」は、サーバプロファイルテーブル３４ｅに記憶されるレコード、言い換えると、ＶＭホストを識別する識別子である。「os＿instance」は、ＶＭホストオブジェクトのリンク先を示す情報であり、ＶＭゲストが動作するＶＭホストを特定する情報である。「vm＿managings」は、ＶＭホストで利用可能なＶＭ管理ソフト、言い換えると、当該ＶＭホストで対応可能なＡＰＩ種別を示し、配列として格納される。図１０の場合、IDが「1」であるＶＭホスト「Host＿a」は、ＡＰ１、ＡＰ２、ＡＰ４に対応していることを示している。なお、図１０に記載される「省略」は、説明上、記載を単に省略したことを示しており、一般的にはＡＰ１などの情報が格納される。
　ＶＭ管理テーブル３４ｆは、サーバプロファイルテーブル３４ｅに記憶されるＶＭホストのＶＭ管理ソフトが属するソフトウェアグループを特定する情報を記憶する。図１１は、ＶＭ管理テーブルに記憶される情報の例を示す図である。図１１に示すように、ＶＭ管理テーブル３４ｆは、「ID、management＿software＿id、logical＿server＿id（SV）」を対応付けて記憶する。
　ここで記憶される「ID」は、サーバプロファイルテーブル３４ｅの各レコードを識別する識別子であり、「management＿software＿id」は、ＶＭ管理ソフトが属するソフトウェアグループを特定する情報である。「logical＿server＿id（SV）」は、サーバプロファイルテーブルのレコードを特定する識別子である。図１１の例で説明すると、ID「1」のレコードは、サーバプロファイルテーブル３４ｅのIDが「8」であるレコードがソフトウェアグループ「1」に属することを示している。同様に、ID「3」のレコードは、サーバプロファイルテーブル３４ｅのIDが「9」であるレコードがソフトウェアグループ「2」に属することを示している。
　管理ソフトテーブル３４ｇは、ＶＭ管理ソフトのソフトウェアグループを記憶する。図１２は、管理ソフトテーブルに記憶される情報の例を示す図である。図１２に示すように、管理ソフトテーブル３４ｇは、「ID、managings」として「1、Managing1，Managing3」や「2、Managing2」などを記憶する。
　ここで記憶される「ID」は、管理ソフトテーブル３４ｇの各レコードを識別するとともに「managings」を識別する識別子であり、ＶＭ管理テーブル３４ｆの「management＿software＿id」に格納される識別子と同様の識別子である。「managings」は、ＶＭ管理ソフトのソフトウェアグループを示す。図１２の例で説明すると、ＶＭ管理ソフトウェアである「Managing1」と「Managing3」は、ID「1」の同じグループに属し、「Managing2」は、ID「2」のグループに属することを示している。
　図２に戻り、ＶＭホスト生成部３５は、移動元となるＶＭホストのリストを生成する。例えば、ＶＭホスト生成部３５は、クライアント装置１０から送信されたＶＭゲストのマイグレーション処理開始指示が通信制御Ｉ／Ｆ部３１等によって受け付けられると、図１３に示すＷｅｂ画面をクライアント装置１０に送信する。図１３は、マイグレーション処理のＴＯＰ画面例を示す図である。図１３に示すＴＯＰ画面は、「Source　VM　Host　List」フィールドと、「Source　VM　Guest　List」フィールドと、「Target　VM　Host　List」フィールドと、「Cold　Migration」フィールドと、「Live　Migration」フィールドとを有する。また、各フィールドには、表示内容を上下左右に移動させるスクロールを設けてもよい。
　「Source　VM　Host　List」フィールドには、移動元のＶＭホストの一覧が表示される。「Source　VM　Guest　List」フィールドには、「Source　VM　Host　List」フィールドに表示されたＶＭホストのうち、ユーザによって選択されたＶＭホスト上で動作するＶＭゲストの一覧が移動対象候補のＶＭゲストとして表示される。「Target　VM　Host　List」フィールドには、移動対象として特定されたＶＭゲストの移動先候補であるＶＭホストの一覧が表示される。「Cold　Migration」フィールドは、移動先ＶＭホストが決定したＶＭゲストのうち、移動種別がコールドマイグレーションと決定されたＶＭゲストの一覧が表示される。「Live　Migration」フィールドは、移動先ＶＭホストが決定したＶＭゲストのうち、移動種別がライブマイグレーションと決定されたＶＭゲストの一覧が表示される。また、「OK」ボタンがクリックされると、「Cold　Migration」フィールドおよび「Live　Migration」フィールドに表示されるＶＭゲストのマイグレーションが開始される。「Cancel」ボタンがクリックされると、マイグレーション処理が終了する。
　ＴＯＰ画面を表示させたＶＭホスト生成部３５は、ＶＭホストテーブル３４ｂの各レコードにおける「NAME」からＶＭホスト名を取得する。そして、ＶＭホスト生成部３５は、取得した各ＶＭホスト名をＴＯＰ画面の「Source　VM　Host　List」フィールドに表示させた画面を生成して、クライアント装置１０に送信する。このとき、ＶＭホスト生成部３５は、ＶＭホストテーブル３４ｂの「ID」と「NAME」とを対応付けて順番に取得し、src＿vm＿hosts変数の配列「0」から順に格納する。なお、格納順序は、配列番号の昇順に限らず、ランダムに取得して、配列にランダムに格納してもよい。
　一例を挙げると、ＶＭホスト生成部３５は、ＴＯＰ画面を表示させた後、図７に示した「NAME」を取得し、取得した「NAME」が表示されるアイコン等を生成する。そして、ＶＭホスト生成部３５は、生成したアイコンを「Source　VM　Host　List」フィールドに表示させた画面を生成して、クライアント装置１０に送信する。また、ＶＭホスト生成部３５は、生成したアイコン順に、src＿vm＿hosts変数の配列に、ＶＭホストテーブル３４ｂの「ID」と「NAME」を格納する。具体的には、ＶＭホスト生成部３５は、１番目に生成したアイコンに表示される「NAME」と「ID」とを配列「0」に格納し、２番目に生成したアイコンに表示される「NAME」と「ID」とを配列「1」に格納する。このようにすることで、ＶＭホスト生成部３５は、アイコンとテーブルの情報とを対応付けることができる。
　図２に戻り、ＶＭゲスト候補生成部３６は、移動対象候補となるＶＭゲストの一覧を生成する。例えば、ＶＭゲスト候補生成部３６は、ＶＭホスト生成部３５が表示した画面の「Source　VM　Host　List」フィールドに表示されるＶＭホストから、通信制御部Ｉ／Ｆ部３１を介してユーザの選択を受け付ける。そして、ＶＭゲスト候補生成部３６は、選択されたＶＭホストで動作しているＶＭゲストを抽出し、抽出したＶＭゲストを「Source　VM　Guest　List」フィールドに表示させた画面をクライアント装置１０に送信する。
　具体例を挙げると、ＶＭゲスト候補生成部３６は、ＶＭホスト生成部３５によって移動元ＶＭホスト一覧が表示されると、src＿vm＿guests変数を生成する。そして、ＶＭゲスト候補生成部３６は、ＶＭホストのアイコンがクリックされると、当該アイコンに対応するsrc＿vm＿hosts変数の配列から、クリックされたＶＭホストを特定する。続いて、ＶＭゲスト候補生成部３６は、特定したＶＭホストに対応付けてsrc＿vm＿guests変数の「NAME」に格納されるＶＭゲスト名を表示させたアイコンを生成する。その後、ＶＭゲスト候補生成部３６は、生成したアイコンを「Source　VM　Guest　List」フィールドに表示させた画面をクライアント装置１０に送信する。つまり、ＶＭゲスト候補生成部３６は、選択されたＶＭホスト上で動作するＶＭゲストを移動対象候補のＶＭゲストとしてユーザに表示する。
　ここで、まず、src＿vm＿guests変数の生成例について説明する。ＶＭゲスト候補生成部３６は、ＶＭホストテーブル３４ｂを参照して、src＿vm＿hosts変数の「NAME＝Host＿b」に対応する「virtual＿machines」として「ＶＭ１０１～ＶＭ１０４」を特定する。そして、ＶＭゲスト候補生成部３６は、「ＶＭ１０１」の「１０１」をキーにして、ＶＭゲストテーブル３４ｄを検索し、「ID＝21」と「NAME＝Guest＿b1」を特定する。また、ＶＭゲスト候補生成部３６は、「ＶＭ１０１」の「１０１」をキーにして、ＶＭテーブル３４ｃを検索し、「vm＿host＿id＝2」を特定する。その後、ＶＭゲスト候補生成部３６は、特定した「vm＿host＿id＝2」を「Hsh＿key」とする配列（array＿index）の「0」に、特定した「ID＝21」と「NAME＝Guest＿b1」を登録したsrc＿vm＿guests変数を生成する。
　同様に、ＶＭゲスト候補生成部３６は、「NAME＝Guest＿b1」と同様に「Host＿b」で動作する「NAME＝Guest＿b2」、「NAME＝Guest＿b3」、「NAME＝Guest＿b4」についても上記処理を実行する。具体的には、ＶＭゲスト候補生成部３６は、「NAME＝Guest＿b2」については、「vm＿host＿id＝2」を「Hsh＿key」とする配列「1」に格納し、「NAME＝Guest＿b3」については配列「2」に格納し、「NAME＝Guest＿b4」については、配列「3」に格納する。このように、ＶＭゲスト候補生成部３６は、src＿vm＿hosts変数に格納されるＶＭホスト各々について、上記処理を実行して図４に示すようなsrc＿vm＿guests変数を生成する。
　このとき、ＶＭゲスト候補生成部３６は、ＶＭテーブル３４ｃを検索した際に、「power＿status」が「unkown」となっているＶＭゲストについてはsrc＿vm＿guests変数に格納しないようにすることもできる。例えば、ＶＭゲスト候補生成部３６は、図８に示した「Guest＿b4」の「power＿status」が「unkown」となっているために、図４のｓ１に示すように、「Guest＿b4」をsrc＿vm＿guests変数に格納していない。
　次に、ＶＭゲスト候補生成部３６がsrc＿vm＿guests変数を生成した状態で、ユーザがＶＭホストを選択した場合に、移動対象候補のＶＭゲストを表示する例について説明する。例えば、ＶＭゲスト候補生成部３６は、ＶＭホストが表示されるアイコンがクリックされると、当該アイコンに対応するsrc＿vm＿hosts変数の配列から、クリックされたＶＭホストを特定する。
　ここでは、ユーザによって「Host＿b」が選択されたとする。この場合、ＶＭゲスト候補生成部３６は、src＿vm＿hosts変数を参照し、「Host＿b」に対応する「ID＝2」を特定する。そして、ＶＭゲスト候補生成部３６は、「ID＝2」をキーにしてsrc＿vm＿guests変数の「Hash＿key」を検索し、「NAME＝Guest＿b1」～「NAME＝Guest＿b3」を特定する。その後、ＶＭゲスト候補生成部３６は、「NAME＝Guest＿b1」～「NAME＝Guest＿b3」各々を示すアイコンを生成して、生成したアイコンを「Source　VM　Guest　List」フィールドに表示させた画面をクライアント装置１０に送信する。なお、ＶＭゲスト候補生成部３６は、array＿indexの順番でアイコンを生成して表示させることで、アイコンとsrc＿vm＿guests変数とを関連付けることもできる。
　図２に戻り、移動先候補生成部３７は、移動対象のＶＭゲストが決定された場合に、移動先対象候補であるＶＭホストの一覧を生成する。具体的には、移動先候補生成部３７は、ユーザの選択によって移動対象のＶＭゲストを特定し、特定したＶＭゲストの移動先候補を生成してユーザに表示する。
　例えば、ユーザが、ＶＭゲスト候補生成部３６によって生成された「Source　VM　Guest　List」フィールドの「Guest＿b2」をクリックしたとする。この場合、移動先候補生成部３７は、クリックされた「Guest＿b2」を移動対象のＶＭゲストとして特定する。続いて、移動先候補生成部３７は、「Guest＿b2」の「Hash＿key＝2」をsrc＿vm＿guests変数から特定し、「Hash＿key＝2」をキーにしてＶＭホストテーブル３４ｂの「ID」を検索する。そして、移動先候補生成部３７は、「Hash＿key＝2」に対応する「NAME＝Host＿b」と「api＿type＝API（B）」をＶＭホストテーブル３４ｂから抽出する。このようにして、移動先候補生成部３７は、移動対象のＶＭゲストが動作するＶＭホストのapi＿type、すなわち移動元ＶＭホストが実行しているＶＭ管理ソフトの種別を特定することができる。
　その後、移動先候補生成部３７は、「api＿type＝API（B）」をキーにしてＶＭホストテーブル３４ｂの「api＿type」を検索し、「api＿type＝API（B）」に対応付けられた「NAME」と「ID」を特定する。図７の例の場合、移動先候補生成部３７は、「api＿type＝API（B）」であるＶＭホストとして「NAME＝Host＿f、ID＝6」と「NAME＝Host＿g、ID＝7」とを特定する。このようにして、移動先候補生成部３７は、移動元ＶＭホストと同様のＶＭ動作環境を提供する移動先候補を特定することができる。
　このとき、移動先候補生成部３７は、移動元ＶＭホストと同一の管理ソフトを有する移動先が存在しない場合には、移動元ＶＭホストが実行する管理ソフトに対応した管理ソフトを実行する移動先を特定するようにしてもよい。さらに、移動先候補生成部３７は、移動元ＶＭホストの管理ソフトと同一ではないが同種の管理ソフトを実行するＶＭホストを特定するようにしてもよい。上記した例の場合、移動先候補生成部３７は、「api＿type＝API（B）」と同一の管理ソフトを実行する「NAME」と「ID」だけでなく、「api＿type＝API（B）」と同種類の「API（B-1）」を実行する「NAME」と「ID」を特定するようにしてもよい。また、別例としては、移動先候補生成部３７は、ＶＭ管理テーブル３４ｆと管理ソフトテーブル３４ｇを参照して、移動元ＶＭホストのＶＭ管理ソフトが属するグループ「manageings」を特定する。そして、移動先候補生成部３７は、特定したグループ「manageings」と同じグループに属するＶＭホストを移動先候補とすることもできる。
　その後、移動先候補生成部３７は、dst＿vm＿hosts変数において、移動元ＶＭホストの「Hash＿key＝2」に対応付けて、「array＿index＝0」に「ID＝6、NAME＝Host＿f」を格納し、「array＿index＝1」に「ID＝7、NAME＝Host＿g」を格納する。このようにして、移動先候補生成部３７は、dst＿vm＿hosts変数を生成する。そして、移動先候補生成部３７は、dst＿vm＿hosts変数に格納される「NAME」が表示されるアイコン等を生成し、生成したアイコン等を「Target　VM　Host　List」フィールドにさらに表示させた画面をクライアント装置１０に送信する。なお、移動先候補生成部３７は、Hash＿keyおよびarray＿indexの順番でアイコンを生成して表示させることで、アイコンとdst＿vm＿hosts変数とを関連付けることもできる。
　図２に戻り、移動判定部３８は、移動対象ＶＭゲストの移動先として特定されたＶＭホストに移動シミュレーションを実行して、移動可能か否かを判定する。例えば、移動判定部３８は、まず、移動先候補生成部３７によって生成された画面からユーザの選択を受け付けて、移動先候補となるＶＭホストを特定する。次に、移動判定部３８は、移動先候補生成部３７が特定した移動対象ＶＭゲストのリソース状況等を用いて、移動先候補のＶＭホストに移動シミュレーションを実行して移動可能か否かを判定する。その後、移動判定部３８は、移動可能と判定した場合には、移動種別決定部３９にその旨を通知して処理を移行し、移動不可能と判定した場合には、ユーザにその旨を報知して別のＶＭホストを選択させる。
　ここで、ユーザ端末が、移動先候補生成部３７によって生成された「Target　VM　Host　List」フィールドに表示される「Host＿c」をクリックしたとする。この場合、移動判定部３８は、移動先候補のＶＭホストを「Host＿c」と特定する。つまり、移動判定部３８は、移動対象のＶＭゲストが「Guest＿b2」であり、移動先候補のＶＭホストを「Host＿c」であると特定する。
　次に、移動判定部３８は、ＶＭホスト「Host＿c」を移動先して既に決定されたＶＭゲストが存在するか否かを、migration＿list変数から判定する。具体的には、移動判定部３８は、migration＿list変数に、「Host＿c」を示す「Hash＿key＝2」であるレコードが存在するか否かを判定する。そして、移動判定部３８は、migration＿list変数に「Hash＿key＝2」が存在しない場合、「Host＿c」を移動先候補とするＶＭゲストが、現在の移動対象である「Guest＿b2」のみであると判定する。
　この場合、移動判定部３８は、「Guest＿b2」のマイグレーションコマンドを「Host＿c」に発行して移動可能か否かを判定する。一手法としては、移動判定部３８は、「Host＿c」で動作しているＶＭゲストの数が「Host＿c」の上限を超えていないかで判定することもできる。また、移動判定部３８は、「Host＿c」のリソース状況をＶＭ管理装置から取得するとともに、「Guest＿b2」のリソース状況をＶＭテーブル３４ｃから取得して、「Host＿c」で「Guest＿b2」が動作可能か否かによって、移動可能か否かを判定することもできる。なお、リソース状況としては、CPU数、メモリ容量、ネットワーク帯域量などが挙げられる。
　一方、migration＿list変数に「Hash＿key＝2」が存在する場合、移動判定部３８は、移動先候補のＶＭホスト「Host＿c」で稼動するＶＭ管理ソフトが、複数マイグレーションに対応しているソフトウェアであるか否かを判定する。一例を挙げると、移動判定部３８は、サーバプロファイルテーブル３４ｅを参照して、移動先候補のＶＭホスト「Host＿c」に対応付けられた「ID」を抽出する。そして、移動判定部３８は、抽出した「ID」に対応付けられた「management＿software＿id」をＶＭ管理テーブル３４ｆから抽出する。さらに、移動判定部３８は、抽出した「management＿software＿id」に対応付けられた「managings」を管理ソフトテーブル３４ｇから特定する。そして、移動判定部３８は、インターネットや管理者等によってメモリ等に登録されている情報等に基づいて、特定した「managings」が複数マイグレーションに対応しているソフトウェア種別であるか否かを判定する。
　そして、移動判定部３８は、複数マイグレーションに対応しているソフトウェアであると判定した場合、「Host＿c」のリソース状況と、既に移動する決定されている他ＶＭゲストのリソース状況とから、「Guest＿b2」が使用可能なリソース状況を特定する。その後、移動判定部３８は、特定したリソース状況下で「Guest＿b2」が動作可能か否かによって、「Guest＿b2」が「Host＿c」に移動可能か否かを判定する。別例としては、移動判定部３８は、「Guest＿b2」および他ＶＭゲストのマイグレーションコマンドを同時に発行して、エラーが発生しないか否かを判定材料とすることもできる。
　また、移動判定部３８は、複数マイグレーションに対応していないソフトウェアであると判定した場合、既に移動が決定されている他ＶＭゲストのリソース状況と、「Guest＿b2」のリソース状況とを加算した１つのリソース状況を生成する。そして、移動判定部３８は、生成した１つのリソース状況が「Host＿c」のリソース状況の範囲内である場合には、「Guest＿b2」が移動可能であると判定する。一方、移動判定部３８は、生成した１つのリソース状況が「Host＿c」のリソース状況の範囲内にない場合には、他ＶＭゲストが「Host＿c」に移動可能であり、「Guest＿b2」が「Host＿c」に移動不可能であると判定する。なお、移動判定部３８は、他ＶＭゲストのリソース状況や「Guest＿b2」のリソース状況をＶＭテーブル３４ｃから取得することができ、「Host＿c」のリソース情報をＶＭ管理装置５０、７０から取得することができる。このようにして、移動判定部３８は、ＶＭゲストの移動先を特定する。
　移動種別決定部３９は、移動判定部３８が特定した移動対象のＶＭゲストの移動種別を決定する。具体的には、移動種別決定部３９は、ＶＭテーブル３４ｃを参照して、移動対象のＶＭゲストの電源状態が「ON」である場合に、当該ＶＭゲストの移動種別を「ライブマイグレーション」と決定する。また、移動種別決定部３９は、ＶＭテーブル３４ｃを参照して、移動対象のＶＭゲストの電源状態が「OFF」である場合に、当該ＶＭゲストの移動種別を「コールドマイグレーション」と決定する。また、移動種別決定部３９は、ＶＭテーブル３４ｃを参照して、移動対象のＶＭゲストの電源状態が「unknown」である場合に、当該ＶＭゲストの移動が「不可能」としてユーザに報知してもよく、移動種別を「コールドマイグレーション」と決定してもよい。
　そして、移動種別決定部３９は、移動種別が「コールドマイグレーション」と決定されたＶＭゲストの「NAME」をＶＭゲストテーブル３４ｄから取得してアイコン等を生成する。その後、移動種別決定部３９は、画面の「Cold　Migration」フィールドに、生成したアイコン等を表示させる。同様に、移動種別決定部３９は、移動種別が「ライブマイグレーション」と決定されたＶＭゲストの「NAME」をＶＭゲストテーブル３４ｄから取得してアイコン等を生成する。その後、移動種別決定部３９は、画面の「Live　Migration」フィールドに、生成したアイコン等を表示させる。その後、移動種別決定部３９は、生成したアイコンが表示される画面をクライアント装置１０に送信する。
　このとき、移動種別決定部３９は、移動先ＶＭホストの「Hash＿key」をＶＭホストテーブル３４ｂ等から取得し、移動対象ＶＭゲストの「ID」をＶＭゲストテーブル３４ｅ等から取得する。そして、移動種別決定部３９は、migration＿lists変数に、「Hash＿key」と「ID」と決定された「マイグレーション種別」とを対応付けて格納する。
　例えば、図６に示す状態で、「Guest＿c2」が「Host＿g」へ「ライブマイグレーションI」すると決定された例について説明する。この場合、移動種別決定部３９は、「Guest＿c2」の「ID＝26」をＶＭゲストテーブル３４ｅから特定し、「Host＿g」の「Hash＿key＝7」をＶＭホストテーブル３４ｂから取得する。そして、migration＿lists変数の「Hash＿key＝7」の配列「0」および「1」に既にデータが登録されていることから、移動種別決定部３９は、「Hash＿key＝7」とする配列「2」に対応付けて、「ID＝26」および「live」をmigration＿lists変数に格納する。
　移動指示部４０は、移動対象であるＶＭゲスト各々について移動先および移動方式が決定された場合に、移動種別決定部３９によって決定された移動先に、移動種別決定部３９によって決定された移動方式で、ＶＭゲスト各々を移動させる。
　例えば図６を例にして説明すると、移動指示部４０は、クライアント装置１０に表示される画面において「OK」がクリックされた場合、migration＿lists変数を参照する。そして、移動指示部４０は、「ID＝22」のＶＭゲストが動作するＶＭホストを管理するＶＭ管理装置５０、７０に、「Hash＿Key＝7」で特定されるＶＭホストへ「コールドマイグレーション」により、「ID＝22」のＶＭゲストを移動させることを指示する。
　このとき、移動指示部４０は、移動対象のＶＭゲストの移動を一気に実行してもよい。また、移動指示部４０は、「migration＿type＝cold」となっているＶＭゲストのマイグレーションを先に実行して完了した後に、「migration＿type＝Live」となっているＶＭゲストのマイグレーションを実行してもよい。そして、移動指示部４０は、migration＿lists変数に格納されるマイグレーションが終了すると、migration＿lists変数を初期値に戻す。
（ＶＭ管理装置の構成）
　次に、ＶＭ管理装置の構成について説明する。図２に示すように、ＶＭ管理装置５０は、通信制御Ｉ／Ｆ部５１とＶＭ構成管理テーブル５２と制御部５３とを有する。
　通信制御Ｉ／Ｆ部５１は、少なくとも１つのポートを有し、移動管理装置３０とＶＭ管理装置５０との間の通信や各サーバ６０とＶＭ管理装置５０との間の通信を制御するインタフェースである。例えば、通信制御Ｉ／Ｆ部５１は、ＶＭ管理装置５０からＶＭゲストのマイグレーション指示を受信したり、各ＶＭホストとの間のマイグレーションに関する各種通信を送受信したりする。
　ＶＭ構成管理テーブル５２は、半導体メモリ素子やハードディスクなどの記憶装置であり、ＶＭ管理装置５０の管理下にあるＶＭホストおよびＶＭゲストに関する情報を記憶する。例えば、ＶＭ構成管理テーブル５２は、サーバのＩＰアドレス、サーバで稼動するＶＭホスト、ＶＭ環境を提供するＶＭ管理ソフト、ＶＭホストで利用可能なリソース状況、動作しているＶＭゲストの数および各リソース状況などを記憶する。なお、ここで記憶される情報は、任意に設定変更でき、管理者等によって登録および更新されてもよく、各サーバから定期的に取得するようにしてもよい。また、ＶＭ管理装置５０の制御部５３は、ＶＭ構成管理テーブル５２が記憶する情報を、移動管理装置３０に定期的に送信するようにしてもよい。
　制御部５３は、内部メモリ等を有するＣＰＵなどの電子回路であり、ＶＭ管理装置５０が実行する各種処理を制御する。例えば、制御部５３は、移動管理装置３０からマイグレーション指示として、「移動種別」と「ＶＭゲスト」と「ＶＭホスト」とを受信する。そして、制御部５３は、「移動種別」が「cold」であれば、指示されたＶＭゲストの移動元ＶＭホストと移動先ＶＭホストとにコールドマイグレーション指示を送信する。なお、ここで実行されるマイグレーションは、一般的なマイグレーションであるので詳細な説明は省略する。例えば、マイグレーション指示とは、移動対象ＶＭゲストの作成指示、メモリ内容をコピーするプレコピー指示およびストップアンドコピー指示、移動が完了したＶＭゲストの起動指示、移動元へのＶＭゲスト削除指示などがある。
（サーバの構成）
　次に、図１に示した各サーバの構成について説明する。図２に示すように、サーバ６０は、通信制御Ｉ／Ｆ部６１と制御部６２とを有する。
　通信制御Ｉ／Ｆ部６１は、少なくとも１つのポートを有し、サーバ６０とＶＭ管理装置５０との間の通信を制御するインタフェースである。例えば、通信制御Ｉ／Ｆ部６１は、上記マイグレーション指示をＶＭ管理装置５０から受信して、制御部６２に通知する。
　制御部６２は、内部メモリ等を有するＣＰＵなどの電子回路であり、サーバ６０における各種処理を実行する。例えば、制御部６２は、ＶＭ管理ソフトを稼動させてＶＭホストを実行し、ＶＭホスト上でＶＭゲストを動作させて仮想マシン環境を実現する。また、制御部６２は、ＶＭ管理装置５０から受信したマイグレーション指示に従って、ＶＭゲスト作成、プレコピー、ストップアンドコピー、ＶＭ起動、ＶＭ削除などのマイグレーション処理を実行する。
［処理の流れ］
　次に、図１４～図１８を用いて、移動管理装置３０が実行する各処理の流れを説明する。ここでは、図１４を用いて全体的な処理の流れを説明し、図１５を用いてＶＭゲスト候補生成処理の流れを説明する。また、図１６を用いて移動先候補のＶＭホストリスト生成処理の流れを説明し、図１７を用いて移動可能判定処理の流れを説明し、図１８を用いて移動種別決定処理の流れを説明する。
（全体的な処理の流れ）
　図１４は、移動管理装置３０が実行する処理の全体的な流れを説明するフローチャートである。図１４に示すように、移動管理装置３０のＶＭホスト生成部３５は、クライアント装置１０からＶＭ処理開始指示を受信すると（Ｓ１０１肯定）、図１３に例示したＴＯＰ画面をクライアント装置１０に送信する（Ｓ１０２）。また、ＶＭ処理開始指示は、入力部３２を介して管理者から受信することもできる。
　続いて、ＶＭホスト生成部３５は、ＴＯＰ画面の「Source　VM　Host　List」フィールドにＶＭホスト名を表示させた画面をクライアント装置１０に送信し、移動元ＶＭホストの選択を受け付ける（Ｓ１０３）。例えば、ＶＭホスト生成部３５は、ＶＭ処理開始指示を受け付けると、ＶＭホストテーブル３４ｂに記憶されるＶＭホストをsrc＿vm＿hosts変数に格納して、移動元ＶＭホストを選択させる画面をクライアント装置１０に送信する。
　そして、ＶＭゲスト候補生成部３６は、移動元ＶＭホストの選択を受け付けると（Ｓ１０３肯定）、選択されたＶＭホストで動作するＶＭゲストを「Source　VM　Guest　List」フィールドに表示させた画面をクライアント装置１０に送信する（Ｓ１０４）。
　続いて、移動先候補生成部３７は、ＶＭゲスト候補生成部３６が生成した画面上で、移動対象とするＶＭゲストの選択を受け付ける（Ｓ１０５肯定）。その後、移動先候補生成部３７は、選択されたＶＭゲストの移動先候補を「Target　VM　Host　List」フィールドに表示させた画面をクライアント装置１０に送信する（Ｓ１０６）。このとき、移動先候補生成部３７は、移動元ＶＭホストのＶＭ管理ソフト等に基づいて、移動先候補のＶＭホストを決定する。
　そして、移動判定部３８は、移動先候補生成部３７が生成した画面上で、移動先候補とするＶＭホストの選択を受け付ける（Ｓ１０７肯定）。その後、移動判定部３８は、Ｓ１０３で選択されたＶＭゲストがＳ１０７で選択されたＶＭホストに移動可能か否かをシミュレーションによって判定する（Ｓ１０８）。
　そして、移動種別決定部３９は、移動判定部３８によって移動可能と判定されたＶＭホストを移動先として決定し（Ｓ１０９肯定）、Ｓ１０３で選択されたＶＭゲストの電源状態に応じて移動種別を決定する（Ｓ１１０）。一方、移動判定部３８は、ユーザが選択したＶＭホストに移動不可能と判定した場合には（Ｓ１０９否定）、Ｓ１０６に戻って、他のＶＭホストをユーザに選択させた後、Ｓ１０７以降の処理を実行する。
　そして、移動指示部４０は、移動対象の全ＶＭゲストに対してＳ１０３～Ｓ１１０までの処理が終了したとユーザが判定し（Ｓ１１１肯定）、クライアント装置１０に表示される画面上で「OK」ボタンがクリックされると（Ｓ１１２肯定）、Ｓ１１３を実行する。すなわち、移動指示部４０は、移動対象であるＶＭゲスト各々について移動先および移動方式が決定された場合に、移動種別決定部３９によって決定された移動先に、移動種別決定部３９によって決定された移動方式で、ＶＭゲスト各々を移動させる。一方、ユーザが他のＶＭゲストに対してもＳ１０３～Ｓ１１０までの処理を実行すると判定した場合（Ｓ１１１否定）、Ｓ１０３以降の処理が繰り返される。
（ＶＭゲスト候補生成処理の流れ）
　図１５は、ＶＭゲスト候補生成処理の流れを説明するフローチャートである。この処理は、図１４に示したＳ１０４～Ｓ１０５で実行される。以降で説明するフローチャートは、ＶＭホスト生成部３５が表示させたＶＭホスト一覧の中から１つのＶＭホストが選択された状態から実行される。
　ＶＭゲスト候補生成部３６は、処理を開始すると初期化を実施する（Ｓ２０１）。すなわち、ＶＭゲスト候補生成部３６は、src＿vm＿guests変数を空にする。また、ＶＭゲスト候補生成部３６は、src＿vm＿guests変数を生成するのに使用する調査リストに、ユーザによって選択されたＶＭホストで動作するＶＭゲストをＶＭホストテーブル３４ｂおよびＶＭゲストテーブル３４ｄから特定して格納する。
　続いて、ＶＭゲスト候補生成部３６は、調査リストに情報が格納されている場合には（Ｓ２０２肯定）、移動対象候補を表示させた画面を生成してクライアント装置１０に送信する。すなわち、ＶＭゲスト候補生成部３６は、src＿vm＿guests変数に格納されたデータに基づいて、移動対象候補を表示させる（Ｓ２０７）。
　また、ＶＭゲスト候補生成部３６は、調査リストに情報が格納されていない場合には（Ｓ２０２否定）、調査リストからＶＭゲストを１つ読み出し、臨時変数としてメモリ等に格納する（Ｓ２０３）。
　続いて、ＶＭゲスト候補生成部３６は、臨時変数に格納したＶＭゲストの電源状態をＶＭテーブル３４ｃから特定し、電源状態が正常であるか否かを判定する（Ｓ２０４）。ここで、ＶＭゲスト候補生成部３６は、当該ＶＭゲストの電源状態が「unknown」でない場合には正常であると判定する。
　そして、ＶＭゲスト候補生成部３６は、当該ＶＭゲストの電源状態が正常である場合には（Ｓ２０４肯定）、当該ＶＭゲストを移動可能候補としてsrc＿vm＿guests変数に格納し（Ｓ２０５）、臨時変数を空にした後に（Ｓ２０６）、Ｓ２０２以降の処理を繰り返す。一方、ＶＭゲスト候補生成部３６は、当該ＶＭゲストの電源状態が正常でない場合には（Ｓ２０４否定）、当該ＶＭゲストを移動可能候補とせずに臨時変数を空にした後に（Ｓ２０６）、Ｓ２０２以降の処理を繰り返す。
（移動先候補のＶＭホストリスト生成処理の流れ）
　図１６は、移動先候補のＶＭホストリスト生成処理の流れを説明するフローチャートである。この処理は、図１４に示したＳ１０６～Ｓ１０７で実行される。
　移動先候補生成部３７は、ユーザによって移動先対象のＶＭゲストが選択されると、当該ＶＭゲストのキーとして、ＶＭゲストと対応付けられてsrc＿vm＿guests変数に格納される「Hash＿key」を取得する（Ｓ３０１）。続いて、移動先候補生成部３７は、「Hash＿key＝2」をキーにしてＶＭホストテーブル３４ｂの「ID」を検索して、「Hash＿key＝2」に対応する「NAME＝Host＿b」と「api＿type＝API（B）」を抽出する（Ｓ３０２）。
　そして、移動先候補生成部３７は、移動先候補ＶＭホストリストを生成するのに使用する一時的なバッファである「管理ソフトリスト」と「移動先ＶＭホスト候補リスト」を空にする初期化を実行する（Ｓ３０３）。
　その後、移動先候補生成部３７は、Ｓ３０２で特定した移動元ＶＭホストの「api＿type」が所定の管理ソフトであるか否かを判定する（Ｓ３０４）。そして、移動先候補生成部３７は、移動元ＶＭホストの「api＿type」が所定の管理ソフトである場合（Ｓ３０４肯定）、所定の管理ソフトを動作させるＶＭホストをＶＭホストテーブル３４ｂから特定して「移動先ＶＭホスト候補リスト」に格納する（Ｓ３０５）。このとき、移動先候補生成部３７は、「移動先ＶＭホスト候補リスト」に格納した情報をdst＿vm＿hosts変数にも格納する。その後、移動先候補生成部３７は、「移動先ＶＭホスト候補リスト」やdst＿vm＿hosts変数に格納されるＶＭホストを、移動先候補のＶＭホストとしてクライアント装置１０に表示させる（Ｓ３０６）。
　なお、所定の管理ソフトであるか否かを判定した後に移動先ＶＭホスト候補を作成する例としては、例えば移動元ＶＭホストと同じメーカの管理ソフトを使用しているか否かなどを判定してもよい。また、仮想化環境を提供する仮想化ソフトウェアのプラットフォームが同じものか否か、すなわち、ハードウェアレベルで提供しているのか、ソフトウェアレベルで提供しているのか、言語レベルなのかを判定してもよい。また、Ｓ３０４およびＳ３０５で実行される別の処理例としては、移動先候補生成部３７は、移動元ＶＭホストの管理ソフトと同一の管理ソフトを動作させるＶＭホストを特定するようにしてもよい。
　一方、移動先候補生成部３７は、移動元ＶＭホストの「api＿type」が所定の管理ソフトでない場合（Ｓ３０４否定）、移動元ＶＭホストの管理ソフトを「管理ソフトリスト」に格納する（Ｓ３０７）。すなわち、移動先候補生成部３７は、移動元ＶＭホストにインストールされて動作する管理ソフトをサーバプロファイルテーブル３４ｅから特定して、「管理ソフトリスト」に格納する。
　そして、移動先候補生成部３７は、「管理ソフトリスト」に格納される管理ソフトが１つ以上である場合（Ｓ３０８肯定）、「管理ソフトリスト」から管理ソフト１つを取得して臨時変数に格納する（Ｓ３０９）。このとき、移動先候補生成部３７は、臨時変数に格納した管理ソフトを「管理ソフトリスト」から削除する。なお、「管理ソフトリスト」に格納される管理ソフトが１つもない場合（Ｓ３０８否定）、移動先候補生成部３７はＳ３１２を実行する。
　続いて、移動先候補生成部３７は、臨時変数に格納した管理ソフトが管理するＶＭホストが１つ以上であるか否かを判定する（Ｓ３１０）。具体的には、移動先候補生成部３７は、臨時変数に格納した管理ソフトが属するソフトウェアグループを管理ソフトテーブル３４ｇから特定する。そして、移動先候補生成部３７は、特定したソフトウェアテーブルに属する管理ソフトを動作させるＶＭホストを、ＶＭ管理テーブル３４ｆおよびＶＭテーブル３４ｃから特定する。こうすることで、移動先候補生成部３７は、移動元ＶＭホストと同種の仮想化環境を提供するＶＭホストを特定することができる。
　そして、移動先候補生成部３７は、臨時変数に格納した管理ソフトが管理するＶＭホストが１つ以上である場合（Ｓ３１０肯定）、当該管理ソフトが管理するＶＭホストを「移動先ＶＭホスト候補リスト」に格納する（Ｓ３１１）。このとき、移動先候補生成部３７は、移動元ＶＭホストについては格納対象外とする。また、移動先候補生成部３７は、「移動先ＶＭホスト候補リスト」に格納した情報をdst＿vm＿hosts変数にも格納する。
　その後、移動先候補生成部３７は、臨時変数に格納される情報を削除する初期化を行って（Ｓ３１２）、Ｓ３０８以降の処理を繰り返す。また、移動先候補生成部３７は、Ｓ３１０において、臨時変数に格納した管理ソフトが管理するＶＭホストが１つもないと判定した場合（Ｓ３１０否定）、Ｓ３１２を実行する。
（移動可能判定処理の流れ）
　図１７は、移動可能判定処理の流れを説明するフローチャートである。この処理は、図１４に示したＳ１０８～Ｓ１０９で実行される。
　移動判定部３８は、移動先候補生成部３７によって特定された移動先候補ＶＭホストリストからユーザによって選択された移動先候補ＶＭホストの「移動決定済みＶＭゲストリスト」が未設定であるか否かを判定する（Ｓ４０１）。すなわち、移動判定部３８は、移動先候補のＶＭホストを移動先とする他のＶＭゲストが存在するか否かを示す「移動決定済みＶＭゲストリスト」が存在するか否かを判定する。
　そして、移動判定部３８は、「移動決定済みＶＭゲストリスト」が未設定である場合（Ｓ４０１肯定）、「移動決定済みＶＭゲストリスト」の初期化を実行する（Ｓ４０２）。例えば、移動判定部３８は、「移動決定済みＶＭゲストリスト」に記憶されるデータを削除する。
　一方、移動判定部３８は、「移動決定済みＶＭゲストリスト」が設定済みである場合（Ｓ４０１否定）、「移動決定済みＶＭゲストリスト」を表示した画面をクライアント装置１０に送信する（Ｓ４０３）。こうすることで、移動判定部３８は、ユーザに、移動決定済みＶＭゲストに対する再考機会を与えることができる。
　その後、移動判定部３８は、移動先候補のＶＭホストを移動先とするＶＭゲストをまとめた「複数ＶＭゲストリスト」を生成する（Ｓ４０４）。続いて、移動判定部３８は、移動先候補のＶＭホストで動作するＶＭ管理ソフトが複数移動に対応しているか否かを、ＶＭ管理テーブル３４ｆに記憶される「managings」などの情報を用いて判定する（Ｓ４０５）。
　そして、移動判定部３８は、ＶＭ管理ソフトが複数移動に対応している場合（Ｓ４０５肯定）、マイグレーションコマンド等の引数に、複数ＶＭゲストを設定し（Ｓ４０６）、シミュレーションを実行する（Ｓ４０７）。その後、移動判定部３８は、シミュレーション結果を表示した画面をクライアント装置１０に送信する（Ｓ４０８）。例えば、移動判定部３８は、同一のＶＭホストに、複数のＶＭゲストのマイグレーションを同時に実行したり、連続して実行したり、先に決定されていたＶＭゲストを移動させた状態で次に移動可能か否かを判定したりするなど任意のシミュレーションを実行する。なお、移動判定部３８は、シミュレーションによる判定手法として、リソース状況の比較コマンドの発行などを実行する。
　一方、移動判定部３８は、ＶＭ管理ソフトが複数移動に対応していない場合（Ｓ４０５否定）、各ＶＭゲストのリソースを加算した１つのＶＭリストを移動条件として生成する（Ｓ４０６）。そして、移動判定部３８は、Ｓ４０７以降で、この移動条件が移動先候補のＶＭゲストで移動可能か否かを判定する。
（移動種別決定処理の流れ）
　図１８は、移動種別決定処理の流れを説明するフローチャートである。この処理は、図１４に示したＳ１１０で実行される。この処理は、移動先が決定されたＶＭゲスト各々について実行される。なお、ここでは、移動種別決定部３９が移動対象のＶＭゲストに適した移動種別を決定する例を説明するが、これに限定されるものではない。例えば、ユーザに適切な移動種別を表示し、ユーザが最終的に移動種別を決定することもできる。
　まず、移動種別決定部３９は、移動判定部３８によって移動対象のＶＭゲストおよび移動先ＶＭホストが決定されると、クライアント装置１０に表示されている画面の移動種別を非活性化にする（Ｓ５０１）。つまり、移動種別決定部３９は、図１３に示した画面上の「Cold　Migration」フィールドおよび「Live　Migration」フィールドを非活性化状態にする。
　続いて、移動種別決定部３９は、移動対象のＶＭゲストの電源状態をＶＭテーブル３４ｃから特定する（Ｓ５０２）。そして、移動種別決定部３９は、当該ＶＭゲストの電源状態が「ON」である場合には、「Cold　Migration」フィールドおよび「Live　Migration」フィールドの両方を活性化する（Ｓ５０３）。その後、移動種別決定部３９は、当該ＶＭゲストのアイコンを「Live　Migration」フィールドに表示させる（Ｓ５０４）。
　また、移動種別決定部３９は、当該ＶＭゲストの電源状態が「OFF」である場合には、「Cold　Migration」フィールドを活性化する（Ｓ５０５）。その後、移動種別決定部３９は、当該ＶＭゲストのアイコンを「Cold　Migration」フィールドに表示させる（Ｓ５０６）。
　また、移動種別決定部３９は、当該ＶＭゲストの電源状態が「unknown」である場合には、「Cold　Migration」フィールドおよび「Live　Migration」フィールドの両方を非活性化する（Ｓ５０７）。すなわち、移動種別決定部３９は、移動不可能と判定する。
　なお、移動種別決定部３９は、Ｓ５０２～Ｓ５０６によって移動種別が決定された場合には、移動先ＶＭホストを示す「Hash＿key」、移動対象ＶＭゲストを示す「ID」、移動種別を示す「migration＿type」を各テーブルおよび各変数から取得する。そして、移動種別決定部３９は、取得した情報を対応付けてmigration＿lists変数に格納する。
［画面遷移例］
　次に、移動管理装置３０がクライアント装置１０に送信する画面の具体例を説明する。ここでは、具体例１として、図１９～図２４を用いて、移動対象のＶＭゲストを決定して移動先を決定した後に移動種別を決定する例を説明する。また、具体例２として、図２５～図４０を用いて、複数のＶＭゲストの移動先を決定する例について説明する。なお、各具体例で説明する画面の基本構成は、図１３と同様である。すなわち、各具体例で説明する画面例は、「Source　VM　Host　List」フィールドと、「Source　VM　Guest　List」フィールドと、「Target　VM　Host　List」フィールドと、「Cold　Migration」フィールドと、「Live　Migration」フィールドとを有する。さらに、各具体例で説明する画面例は、「OK」ボタンと「Cancel」ボタンとを有する。
（具体例１）
　図１９は、ＴＯＰ画面例を示す図であり、図２０は、移動対象のＶＭゲスト一覧を表示させた画面例を示す図であり、図２１は、移動先候補のＶＭホスト一覧を表示させた画面例を示す図である。図２２は、移動先候補として１つのＶＭホストが選択された画面例を示す図であり、図２３は、移動先のＶＭホストが決定された画面例を示す図であり、図２４は、移動種別が決定された画面例を示す図である。
　移動管理装置３０のＶＭホスト生成部３５は、クライアント装置１０から送信されたＶＭゲストのマイグレーション処理開始指示が通信制御Ｉ／Ｆ部３１等によって受け付けられると、図１９に示すＴＯＰ画面をクライアント装置１０に送信する。具体的には、ＶＭホスト生成部３５は、図１３に示した各フィールドを有する画面において、ＶＭホストテーブル３４ｂ等から取得したＶＭホスト名（NAME）を「Source　VM　Host　List」フィールドに表示させた画面をクライアント装置１０に送信する。ここでは、ＶＭホスト生成部３５は、「Host＿a」、「Host＿b」、「Host＿c」を表示したとする。
　続いて、ＶＭゲスト候補生成部３６は、図１９の画面例において「Host＿c」がクライアント装置１０によって選択されると、移動元ＶＭホストを「Host＿c」と決定する。続いて、ＶＭゲスト候補生成部３６は、各テーブルを参照し、「Host＿c」で動作しているＶＭゲストとして「Guest＿c1」と「Guest＿c3」を抽出する。そして、ＶＭゲスト候補生成部３６は、図２０に示すように、「Guest＿c1」と「Guest＿c3」を「Source　VM　Guest　List」フィールドに表示させた画面をクライアント装置１０に送信する。
　その後、移動先候補生成部３７は、図２０の画面例において「Guest＿c1」がクライアント装置１０において選択されると、各テーブルを参照して、移動元ＶＭホスト「Host＿c」と同種または同一のＶＭ管理ソフトを動作させる他のＶＭホストを特定する。続いて、移動先候補生成部３７は、図２１に示すように、移動先候補のＶＭホストとして「Host＿a」、「Host＿d」、「Host＿e」を「Target　VM　Host　List」フィールドに表示させた画面をクライアント装置１０に送信する。
　この状態で、図２２に示すように、クライアント装置１０によって「Host＿a」が選択された場合、移動判定部３８は、移動対象ＶＭゲスト「Guest＿c1」が「Host＿a」に移動可能か否かを移動シミュレーションによって判定する。そして、移動種別決定部３９は、移動判定部３８が移動可能と判定した場合、ＶＭゲスト「Guest＿c」の電源状態が「ON」であることをＶＭゲストテーブル３４ｅから特定する。その後、移動種別決定部３９は、図２３に示すように、「Cold　Migration」フィールドと「Live　Migration」フィールドとを活性化した状態の画面をクライアント装置１０に送信する。この状態の画面例は、「Source　VM　Host　List」フィールドの「Host＿c」、「Source　VM　Guest　List」フィールドの「Guest＿c1」、「Target　VM　Host　List」フィールドの「Host＿a」が選択された状態である。
　その後、移動種別決定部３９は、図２４に示すように、ＶＭゲスト「Guest＿c」の電源状態が「ON」であることより、「Live　Migration」フィールドに「Guest＿c」を表示させた画面をクライアント装置１０に送信する。このようにして、各ＶＭゲストに対して移動種別が決定された後に、「OK」がクリックされると、移動指示部４０は、migration＿lists変数を参照し、「Live　Migration」フィールドに表示される「Guest＿c」の移動の開始指示をＶＭ管理装置に送信する。そして、ＶＭ管理装置は、移動元ＶＭホストおよび移動先ＶＭホストのそれぞれに、ライブマイグレーション指示を送信する。
（具体例２）
　図２５は、ＴＯＰ画面例を示す図であり、図２６は、移動対象のＶＭゲスト一覧を表示させた画面例を示す図であり、図２７は、移動先候補のＶＭホスト一覧を表示させた画面例を示す図である。図２８は、移動先候補として１つのＶＭホストが選択された画面例を示す図であり、図２９は、移動先のＶＭホストが決定された画面例を示す図であり、図３０は、移動種別が決定された画面例を示す図である。
　図３１は、既に他のＶＭゲストの移動が決定された状態で別の移動元ＶＭホストが選択された画面例を示す図であり、図３２は、図３１の状態から移動対象のＶＭゲストが選択された画面例を示す図である。図３３は、図３２の状態から移動先候補のＶＭホストが選択された画面例を示す図であり、図３４は、図３３の状態から移動先のＶＭホストが決定した画面例を示す図であり、図３５は、図３４の状態から移動種別が決定された画面例を示す図である。
　図３６は、図３５の状態からさらに続けて他のＶＭゲストの移動先を決定する画面例を示す図であり、図３７は、図３６の状態から移動先対象のＶＭゲストが選択された画面例を示す図である。図３８は、移動先候補として選択されたＶＭホストに既に別のＶＭゲストの移動が決定されている画面例を示す図である。図３９は、図３８の状態から移動種別が決定された画面例を示す図であり、図４０は、１つのＶＭホストに複数のＶＭゲストが移動することが決定された画面例を示す図である。
　移動管理装置３０のＶＭホスト生成部３５は、クライアント装置１０から送信されたＶＭゲストのマイグレーション処理開始指示が通信制御Ｉ／Ｆ部３１等によって受け付けられると、図２５に示すＴＯＰ画面をクライアント装置１０に送信する。具体的には、ＶＭホスト生成部３５は、ＶＭホストテーブル３４ｂ等から取得したＶＭホスト名（NAME）を「Source　VM　Host　List」フィールドに表示させた画面をクライアント装置１０に送信する。ここでは、ＶＭホスト生成部３５は、「Host＿a」、「Host＿b」、「Host＿c」を表示したとする。
　続いて、ＶＭゲスト候補生成部３６は、図２５の画面例において「Host＿b」がクライアント装置１０によって選択されると、移動元ＶＭホストを「Host＿b」と決定する。続いて、ＶＭゲスト候補生成部３６は、各テーブルを参照し、「Host＿b」で動作しているＶＭゲストとして「Guest＿b1」と「Guest＿b2」と「Guest＿b3」とを抽出する。そして、ＶＭゲスト候補生成部３６は、図２６に示すように、「Guest＿b1」と「Guest＿b2」と「Guest＿b3」を「Source　VM　Guest　List」フィールドに表示させた画面をクライアント装置１０に送信する。
　その後、移動先候補生成部３７は、図２６の画面例において「Guest＿b2」がクライアント装置１０において選択されると、各テーブルを参照し、移動元ＶＭホスト「Host＿b」と同種または同一のＶＭ管理ソフトを動作させる他のＶＭホストを特定する。続いて、移動先候補生成部３７は、図２７に示すように、移動先候補のＶＭホストとして、「Host＿f」、「Host＿g」を「Target　VM　Host　List」フィールドに表示させた画面をクライアント装置１０に送信する。
　この状態で、図２８に示すように、クライアント装置１０によって「Host＿g」が選択された場合、移動判定部３８は、移動対象ＶＭゲスト「Guest＿b2」が「Host＿g」に移動可能か否かを移動シミュレーションによって判定する。そして、移動種別決定部３９は、移動判定部３８が移動可能と判定した場合、移動対象ＶＭゲスト「Guest＿b2」の電源状態に基づいてフィールドを活性化させた画面をクライアント装置１０に送信する。
　ここでは、移動種別決定部３９は、ＶＭゲスト「Guest＿b2」の電源状態が「OFF」であることをＶＭゲストテーブル３４ｅから特定する。すると、移動種別決定部３９は、図２９に示すように、「Cold　Migration」フィールドを活性化した状態の画面をクライアント装置１０に送信する。その後、移動種別決定部３９は、図３０に示すように、ＶＭゲスト電源状態が「OFF」である「Guest＿b2」を「Cold　Migration」フィールドに表示させた画面をクライアント装置１０に送信する。
　続いて、図３０の状態から「Source　VM　Host　List」フィールドの「Host＿c」がクライアント装置１０において選択されると、ＶＭゲスト候補生成部３６は、移動元ＶＭホストを「Host＿c」と決定する。続いて、ＶＭゲスト候補生成部３６は、各テーブルを参照して、「Host＿c」で動作しているＶＭゲストとして「Guest＿c1」と「Guest＿c3」を抽出する。そして、ＶＭゲスト候補生成部３６は、図３１に示すように、「Guest＿c1」と「Guest＿c3」を「Source　VM　Guest　List」フィールドに表示させた画面をクライアント装置１０に送信する。
　その後、移動先候補生成部３７は、図３１の画面例において「Guest＿c1」がクライアント装置１０によって選択されると、各テーブルを参照して、移動元ＶＭホスト「Host＿c」と同種または同一のＶＭ管理ソフトを動作させる他のＶＭホストを特定する。続いて、移動先候補生成部３７は、図３２に示すように、移動先候補のＶＭホストとして「Host＿a」、「Host＿d」、「Host＿e」を「Target　VM　Host　List」フィールドに表示させた画面をクライアント装置１０に送信する。
　この状態で、図３３に示すように、クライアント装置１０において「Host＿a」が選択された場合、移動判定部３８は、移動対象ＶＭゲスト「Guest＿c1」が「Host＿a」に移動可能か否かを移動シミュレーションによって判定する。そして、移動種別決定部３９は、移動判定部３８が移動可能と判定した場合、移動対象ＶＭゲスト「Guest＿c1」の電源状態に基づいてフィールドを活性化させた画面をクライアント装置１０に送信する。ここでは、移動種別決定部３９は、ＶＭゲスト「Guest＿c1」の電源状態が「ON」であることをＶＭゲストテーブル３４ｅから特定する。そして、移動種別決定部３９は、図３４に示すように、「Cold　Migration」フィールドと「Live　Migration」フィールドとを活性化した状態の画面をクライアント装置１０に送信する。
　その後、図３５に示すように、移動種別決定部３９は、ＶＭゲスト「Guest＿c1」の電源状態が「ON」であることより、「Live　Migration」フィールドに「Guest＿c1」を表示させた画面をクライアント装置１０に送信する。つまり、ここまでの状態では、移動管理装置３０は、ＶＭホスト「Host＿b」で動作する「Guest＿b2」を「コールドマイグレーション」で「Host＿g」に移動させることが決定されている。さらに、移動管理装置３０は、ＶＭホスト「Host＿c」で動作する「Guest＿c1」を「ライブマイグレーション」で「Host＿a」に移動させることが決定されている。
　さらに続いて、図３６に示すように、図３５の状態から「Source　VM　Host　List」フィールドの「Host＿b」がクライアント装置１０において選択されると、ＶＭゲスト候補生成部３６は、移動元ＶＭホストを「Host＿b」と決定する。続いて、ＶＭゲスト候補生成部３６は、各テーブルを参照して、「Host＿b」で動作しているＶＭゲストとして「Guest＿b1」と「Guest＿b3」を抽出する。そして、ＶＭゲスト候補生成部３６は、図３６に示すように、「Guest＿b1」と「Guest＿b3」を「Source　VM　Guest　List」フィールドに表示させた画面をクライアント装置１０に送信する。ここで、クライアント装置１０が「Guest＿b3」を選択したとする。なお、ＶＭゲスト候補生成部３６は、「Guest＿b2」については、既に移動先が決定されているので、「Host＿b」が移動元と選択されたとしても移動対象からは除外する。
　その後、移動先候補生成部３７は、「Guest＿b3」がクライアント装置１０において選択されると、各テーブルを参照して、移動元ＶＭホスト「Host＿b」と同種または同一のＶＭ管理ソフトを動作させる他のＶＭホストを特定する。すなわち、移動先候補生成部３７は、図３７に示すように、移動先候補のＶＭホストとして、「Host＿f」、「Host＿g」を「Target　VM　Host　List」フィールドに表示させた画面をクライアント装置１０に送信する。
　この状態で、図３８に示すように、クライアント装置１０において「Host＿g」が選択された場合、移動判定部３８は、移動対象ＶＭゲスト「Guest＿b3」が「Host＿g」に移動可能か否かを移動シミュレーションによって判定する。
　このとき、移動判定部３８は、「Guest＿b2」の移動先として「Host＿g」が既に決定されているので、クライアント装置１０が「Host＿g」が選択すると、「Cole　Migration」フィールドに「Guest＿b2」を表示させた画面をクライアント装置１０に送信する。また、移動判定部３８は、「Host＿g」が「Guest＿b2」の移動先として決定されている状態で、新たな「Guest＿b3」の移動先候補として選択されたことから、両方が移動可能か否かを判定する。なお、判定手法については、構成等で説明したので省略する。また、移動判定部３８は、図３８の状態では、「Guest＿b3」の電源状態を特定していないので、「Cold　Migration」フィールドと「Live　Migration」フィールドとを非活性化にした状態で、「Cold　Migration」フィールドに「Guest＿b2」を表示させる。
　そして、移動種別決定部３９は、移動判定部３８が移動可能と判定した場合、移動対象ＶＭゲスト「Guest＿b3」の電源状態に基づいてフィールドを活性化させた画面をクライアント装置１０に送信する。ここでは、移動対象ＶＭゲスト「Guest＿b3」の電源状態が「ON」であることより、移動種別決定部３９は、図３９に示すように、「Cold　Migration」フィールドと「Live　Migration」フィールドとを活性化した状態の画面をクライアント装置１０に送信する。
　その後、図４０に示すように、移動種別決定部３９は、ＶＭゲスト「Guest＿b3」の電源状態が「ON」であることより、「Live　Migration」フィールドに「Guest＿b3」を表示させた画面をクライアント装置１０に送信する。つまり、ここまでの状態では、移動管理装置３０は、ＶＭホスト「Host＿b」で動作する「Guest＿b2」を「コールドマイグレーション」で「Host＿g」に移動させることが決定されている。さらに、移動管理装置３０は、ＶＭホスト「Host＿c」で動作する「Guest＿c1」を「ライブマイグレーション」で「Host＿a」に移動させることが決定されている。さらに、移動管理装置３０は、ＶＭホスト「Host＿b」で動作する「Guest＿b3」を「ライブマイグレーション」で「Host＿g」に移動させることが決定されている。
　このようにして、各ＶＭゲストに対して移動種別が決定された後に、「OK」がクリックされると、移動指示部４０は、移動先および移動種別が決定されたＶＭゲストのマイグレーションを実行する。具体的には、移動指示部４０は、migration＿lists変数を参照し、「Cold　Migration」フィールドおよび「Live　Migration」フィールドに表示される各ＶＭゲストの移動の開始指示をＶＭ管理装置に送信する。そして、ＶＭ管理装置は、移動元ＶＭホストおよび移動先ＶＭホストのそれぞれに、マイグレーション指示を送信する。この結果、各ＶＭホストは、指示されたＶＭゲストに対してマイグレーションを実行できる。
［実施例２による効果］
　実施例２によれば、ＶＭホストやＶＭ管理装置の負荷を意識することなく、任意のＶＭゲストの移動を複数ＶＭホストに移動できる。移動管理装置３０は、ＶＭゲストのマイグレーションに関する処理の内容をＷｅｂ画面でクライアント装置に送信するので、ユーザは、簡単な操作で複数の移動設定を行うことができる。
　移動管理装置３０は、一括でＶＭゲストの移動指示を実行できるため、管理者は、移動設定および移動実施後の正常終了の確認など、ＶＭゲストの移動処理を実行するのに要する拘束時間を短縮することができる。この結果、管理者は、仕事の効率の向上も図れる。また、ＶＭゲストを１つずつ移動させるより、全体移動処理時間を短縮することができ、サーバの負荷軽減にも繋がる。
　さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。
（Ｗｅｂ画面）
　実施例２では、移動管理装置３０がＷｅｂ画面を生成してクライアント装置１０に送信する例について説明したが、これに限定されるものではない。例えば、移動管理装置３０は、自装置が有する表示部３３に表示させて、表示部３３に表示させた画面からユーザの操作を受け付けるようにしてもよい。また、移動管理装置３０は、移動種別の結果などについて、アイコンに対するドラッグ＆ドロップを受け付けて、ユーザの選択を受け付けることもできる。
（自動実行）
　例えば、移動管理装置３０は、Ｗｅｂ画面を生成してユーザに問い合わせずに、各テーブルの情報を用いて、移動先ＶＭホストや移動種別を決定することもできる。つまり、移動管理装置３０は、移動対象であるＶＭゲスト各々を各テーブルから特定する。そして、移動管理装置３０は、各ＶＭゲストについて、当該ＶＭゲストの移動をシミュレーションして、移動先を決定する。さらに、移動管理装置３０は、移動先が決定されたＶＭゲストの電源状態に基づいて、当該ＶＭゲストの移動方式を決定する。その後、移動管理装置３０は、移動対象であるＶＭゲスト各々について移動先および移動方式が決定された場合に、決定された移動先に、決定された移動方式で、ＶＭゲスト各々を移動させる。
　このように、移動管理装置３０が、各テーブルを用いて、全ての処理を自動で実行することもできる。また、移動管理装置３０は、実施例２等で説明した処理のうち、移動種別決定結果など一部分だけをＷｅｂ画面として生成するようにしてもよい。つまり、移動管理装置３０は、移動種別等を自動で決定できるだけでなく、ユーザからの指定をクライアント装置１０に表示させた画面等から受け付けることもできる。この場合、移動管理装置３０は、管理者等の指示または設定によって、自動決定を優先してもよく、ユーザ指定を優先してもよい。
（マイグレーション指示順序）
　実施例２では、コールドマイグレーションを先に実行した後に、ライブマイグレーションを実行する例について説明したが、これに限定されるものではない。例えば、管理者等によって、移動先ホスト等が指定されている場合には、指定された移動先ホストへのマイグレーションを実行した後に、他の移動先にマイグレーションを実行することができる。したがって、移動先ホストや移動元ホストの負荷状況、ＶＭ管理装置の負荷状況、ネットワーク使用率等を考慮して、任意に設定変更することができる。
（システム）
　また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、例えば図３～図１２等に示した各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
　また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、例えば移動判定部３８と移動種別決定部３９とを統合するなど各装置の分散・統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
（プログラム）
　ところで、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、上記の実施例と同様の機能を有するプログラムを実行するコンピュータシステムの一例を説明する。
　図４１は、移動管理プログラムを実行するコンピュータの例を示す図である。図４１に示すように、コンピュータ１００は、ＲＡＭ１０１と、ＨＤＤ１０２と、ＲＯＭ１０３と、ＣＰＵ１０４と、記録媒体読み取り装置１０５とを有する。ＨＤＤ１０２には、図２に示したテーブル３４ａ～３４ｇ各々と同様の機能を有するテーブルが設けられる。すなわち、ＨＤＤ１０２には、変数管理テーブル１０２ａ、ＶＭホストテーブル１０２ｂ、ＶＭテーブル１０２ｃ、ＶＭゲストテーブル１０２ｄ、サーバプロファイルテーブル１０２ｅ、ＶＭ管理テーブル１０２ｆ、管理ソフトテーブル１０２ｇが設けられる。
　ＲＯＭ１０３には、上の実施例と同様の機能を発揮するプログラムがあらかじめ記憶されている。つまり、図４１に示すように、ＲＯＭ１０３には、移動管理プログラム１０３ａがあらかじめ記憶されている。
　そして、ＣＰＵ１０４には、移動管理プログラム１０３ａを読み出して実行することで、図４１に示すように、移動管理プロセス１０４ａを実行する。移動管理プロセス１０４ａは、図２に示した各制御部と同様の動作を実行する。すなわち、移動管理プロセス１０４ａは、ＶＭホスト生成部３５、ＶＭゲスト候補生成部３６、移動先候補生成部３７、移動判定部３８、移動種別決定部３９、移動指示部４０と同様の動作を実行する。
　ところで、上記した移動管理プログラム１０３ａは、必ずしもＲＯＭ１０３に記憶させておく必要はない。例えば、コンピュータ１００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ－ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に記憶させておくようにしてもよい。また、コンピュータ１００の内外に備えられるハードディスクドライブ（ＨＤＤ）などの「固定用の物理媒体」に記憶させておいてもよい。さらに、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される「他のコンピュータ」に記憶させておいてもよい。そして、コンピュータ１００がこれらからプログラムを読み出して実行するようにしてもよい。
　すなわち、この他の実施例でいうプログラムは、上記した「可搬用の物理媒体」、「固定用の物理媒体」、「通信媒体」などの記録媒体に、コンピュータ読み取り可能に記録されるものである。例えば、コンピュータ１００は、記録媒体読み取り装置１０５によって記録媒体から移動管理プログラムを読み出し、読み出された移動管理プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、コンピュータ１００によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。
　１０　クライアント装置
　３０　移動管理装置
　３０ａ　第１決定部
　３０ｂ　第２決定部
　３０ｃ　移動処理部
　３１　通信制御Ｉ／Ｆ部
　３２　入力部
　３３　表示部
　３４　記憶部
　３４ａ　変数管理テーブル
　３４ｂ　ＶＭホストテーブル
　３４ｃ　ＶＭテーブル
　３４ｄ　ＶＭ管理テーブル
　３４ｅ　ＶＭゲストテーブル
　３４ｆ　サーバプロファイルテーブル
　３４ｇ　管理ソフトテーブル
　３５　ＶＭホスト生成部
　３６　ＶＭゲスト候補生成部
　３７　移動先候補生成部
　３８　移動判定部
　３９　移動種別決定部
　４０　移動指示部
　５０、７０　ＶＭ管理装置
　５１　通信制御Ｉ／Ｆ部
　５２　ＶＭ構成管理テーブル
　５３　制御部
　６０　サーバ
　６１　通信制御Ｉ／Ｆ部
　６２　制御部

Claims (10)

  1. 　移動対象である仮想マシン各々について、当該仮想マシンの移動をシミュレーションして、移動先を決定する第１決定部と、
    　前記第１決定部によって移動先が決定された仮想マシンの電源状態に基づいて、当該仮想マシンの移動方式を決定する第２決定部と、
    　前記移動対象である仮想マシン各々について移動先および移動方式が決定された場合に、前記第１決定部によって決定された移動先に、前記第２決定部によって決定された移動方式で、前記仮想マシン各々を移動させる移動処理部と
    　を有することを特徴とする移動管理装置。
  2. 　前記仮想マシン各々が動作する動作環境に基づいて、前記仮想マシン各々の移動先候補を特定する特定部と、
    　前記特定部によって特定された移動先候補に、前記仮想マシンの移動をシミュレーションして前記仮想マシンが移動可能か否かを判定する判定部と、をさらに有し、
    　前記第１決定部は、前記判定部によって移動可能と判定された移動先候補を移動先として決定することを特徴とする請求項１に記載の移動管理装置。
  3. 　前記第１決定部は、各サーバで動作する仮想マシンのうち電源状態が検出できた仮想マシンを移動対象候補として検出し、検出した移動対象候補のうち指定された仮想マシンを移動対象の仮想マシンとすることを特徴とする請求項１に記載の移動管理装置。
  4. 　前記判定部は、シミュレーション対象である仮想マシンの移動先として特定された移動先候補が他の仮想マシンの移動先として決定されている状態で、当該移動先候補の動作環境が複数の仮想マシンが移動できる動作環境である場合には、前記他の仮想マシンが前記移動先候補に移動したと仮定した状態で、前記シミュレーション対象である仮想マシンが前記移動先候補に移動可能か否かを判定することを特徴とする請求項２に記載の移動管理装置。
  5. 　前記判定部は、シミュレーション対象である仮想マシンの移動先として特定された移動先候補が他の仮想マシンの移動先として決定されている状態で、当該移動先候補の動作環境が複数の仮想マシンが移動できる動作環境でない場合には、所定の条件に基づいて、前記シミュレーション対象である仮想マシンおよび前記他の仮想マシンから移動条件を生成し、生成した移動条件に基づいて、前記シミュレーション対象である仮想マシンおよび前記他の仮想マシンが前記移動先候補に移動可能か否かを判定することを特徴とする請求項２に記載の移動管理装置。
  6. 　前記第２決定部は、仮想マシンの電源状態が起動中である場合には、当該仮想マシンの移動方式をライブマイグレーションと決定し、仮想マシンの電源状態が停止中である場合には、当該仮想マシンの移動方式をコールドマイグレーションと決定することを特徴とする請求項１に記載の移動管理装置。
  7. 　前記第２決定部は、前記仮想マシン各々に対して移動方式が指定されている場合には、前記電源状態に関らず、指定された移動方式で移動させると決定することを特徴とする請求項１に記載の移動管理装置。
  8. 　前記移動処理部は、前記仮想マシン各々を移動させる場合に、コールドマイグレーションによる移動を先に実行し、コールドマイグレーションによる仮想マシンの移動が完了した後に、ライブマイグレーションによる移動を実行することを特徴とする請求項１に記載の移動管理装置。
  9. 　コンピュータが実行する制御方法であって、
    　移動対象である仮想マシン各々について、当該仮想マシンの移動をシミュレーションして、移動先を決定し、
    　移動先を決定した仮想マシンの電源状態に基づいて、当該仮想マシンの移動方式を決定し、
    　移動対象である仮想マシン各々について移動先および移動方式が決定した場合に、前記決定した移動先に、前記決定した移動方式で、前記仮想マシン各々を移動させる、
    　ことを特徴とする移動管理方法。
  10. 　コンピュータに、
    　移動対象である仮想マシン各々について、当該仮想マシンの移動をシミュレーションして、移動先を決定し、
    　移動先を決定した仮想マシンの電源状態に基づいて、当該仮想マシンの移動方式を決定し、
    　移動対象である仮想マシン各々について移動先および移動方式が決定した場合に、前記決定した移動先に、前記決定した移動方式で、前記仮想マシン各々を移動させる処理、
    　をコンピュータに実行させることを特徴とする移動管理プログラム。
PCT/JP2011/056851 2011-03-22 2011-03-22 移動管理装置、移動管理方法および移動管理プログラム WO2012127633A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP11861444.5A EP2690553A4 (en) 2011-03-22 2011-03-22 MIGRATION MANAGEMENT DEVICE, MIGRATION MANAGEMENT PROCESS AND MIGRATION MANAGEMENT PROGRAM
JP2013505703A JP5804050B2 (ja) 2011-03-22 2011-03-22 移動管理装置、移動管理方法および移動管理プログラム
PCT/JP2011/056851 WO2012127633A1 (ja) 2011-03-22 2011-03-22 移動管理装置、移動管理方法および移動管理プログラム
US14/031,410 US9244731B2 (en) 2011-03-22 2013-09-19 Migration management apparatus and migration management method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2011/056851 WO2012127633A1 (ja) 2011-03-22 2011-03-22 移動管理装置、移動管理方法および移動管理プログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/031,410 Continuation US9244731B2 (en) 2011-03-22 2013-09-19 Migration management apparatus and migration management method

Publications (1)

Publication Number Publication Date
WO2012127633A1 true WO2012127633A1 (ja) 2012-09-27

Family

ID=46878826

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/056851 WO2012127633A1 (ja) 2011-03-22 2011-03-22 移動管理装置、移動管理方法および移動管理プログラム

Country Status (4)

Country Link
US (1) US9244731B2 (ja)
EP (1) EP2690553A4 (ja)
JP (1) JP5804050B2 (ja)
WO (1) WO2012127633A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015001827A (ja) * 2013-06-14 2015-01-05 日本電信電話株式会社 管理装置、管理方法、管理プログラムおよび通信システム

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9323563B2 (en) * 2012-02-28 2016-04-26 Red Hat Israel, Ltd. Determining virtual machine migration in view of a migration rule
CN104239083A (zh) * 2013-06-21 2014-12-24 中兴通讯股份有限公司 移动终端的应用的迁移方法、装置以及系统
US9274824B2 (en) * 2013-06-27 2016-03-01 Verizon Patent And Licensing Inc. Network technology standard operating environment
IN2013CH05013A (ja) * 2013-11-07 2015-05-08 Schneider Electric It Corp
US9529828B1 (en) * 2013-12-24 2016-12-27 EMC IP Holding Company LLC Automating configuration and migrating configurations of assets in a storage area network
EP3158435A1 (en) * 2014-06-17 2017-04-26 Nokia Solutions and Networks Oy Methods and apparatus to control a virtual machine
US20160077854A1 (en) * 2014-09-12 2016-03-17 International Business Machines Corporation Expediting host maintenance mode in cloud computing environments
US9830349B2 (en) * 2014-10-31 2017-11-28 Vmware, Inc. Maintaining storage profile consistency in a cluster having local and shared storage
US10067800B2 (en) * 2014-11-06 2018-09-04 Vmware, Inc. Peripheral device sharing across virtual machines running on different host computing systems
US9612765B2 (en) * 2014-11-19 2017-04-04 International Business Machines Corporation Context aware dynamic composition of migration plans to cloud
US9740413B1 (en) * 2015-03-30 2017-08-22 EMC IP Holding Company LLC Migrating data using multiple assets
EP3311272B1 (en) * 2015-06-16 2023-04-12 Telefonaktiebolaget LM Ericsson (PUBL) A method of live migration
US9946564B2 (en) * 2015-06-23 2018-04-17 International Business Machines Corporation Adjusting virtual machine migration plans based on alert conditions related to future migrations
US10129331B2 (en) * 2015-06-25 2018-11-13 Vmware, Inc. Load balancing using a client swapping operation
US10628195B2 (en) 2015-10-22 2020-04-21 Genband Us Llc High availability for virtual network functions
WO2017167688A1 (en) * 2016-03-29 2017-10-05 Nokia Solutions And Networks Oy Methods and apparatuses for moving virtualized network function instances between network service instances
US10419547B1 (en) * 2017-04-10 2019-09-17 Plesk International Gmbh Method and system for composing and executing server migration process
JP6901683B2 (ja) * 2017-09-22 2021-07-14 富士通株式会社 調整プログラム、調整装置および調整方法
CN109617954B (zh) * 2018-11-29 2021-07-30 郑州云海信息技术有限公司 一种创建云主机的方法和装置
JP7193732B2 (ja) * 2019-04-08 2022-12-21 富士通株式会社 管理装置、情報処理システムおよび管理プログラム
US11409619B2 (en) 2020-04-29 2022-08-09 The Research Foundation For The State University Of New York Recovering a virtual machine after failure of post-copy live migration

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007536657A (ja) 2004-05-08 2007-12-13 インターナショナル・ビジネス・マシーンズ・コーポレーション 仮想マシン・コンピュータ・プログラムの動的マイグレーション
US20080196026A1 (en) * 2007-02-12 2008-08-14 Alain Charles Azagury Device, method and computer program product for executing a migrated execution context by a storage controller
JP2008217302A (ja) 2007-03-02 2008-09-18 Nec Corp 仮想マシンシステム、管理サーバ、仮想マシン移行方法及びプログラム
US20090119087A1 (en) * 2007-11-06 2009-05-07 Vmware, Inc. Pass-through and emulation in a virtual machine environment
JP2010117760A (ja) 2008-11-11 2010-05-27 Hitachi Ltd 仮想マシン移動管理サーバおよび仮想マシン移動方法
JP2010244524A (ja) * 2009-03-17 2010-10-28 Hitachi Ltd 仮想サーバの移動方法の決定方法及びその管理サーバ
JP2011008780A (ja) * 2009-06-25 2011-01-13 Vmware Inc 仮想インフラストラクチャを用いた情報技術リスク管理

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8141075B1 (en) * 2006-05-08 2012-03-20 Vmware, Inc. Rule engine for virtualized desktop allocation system
US20100030877A1 (en) * 2007-02-23 2010-02-04 Mitsuru Yanagisawa Virtual server system and physical server selecting method
US8191063B2 (en) * 2007-09-30 2012-05-29 Symantex Corporation Method for migrating a plurality of virtual machines by associating files and state information with a single logical container
US7904540B2 (en) * 2009-03-24 2011-03-08 International Business Machines Corporation System and method for deploying virtual machines in a computing environment
US9626206B2 (en) * 2010-03-18 2017-04-18 Microsoft Technology Licensing, Llc Virtual machine homogenization to enable migration across heterogeneous computers

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007536657A (ja) 2004-05-08 2007-12-13 インターナショナル・ビジネス・マシーンズ・コーポレーション 仮想マシン・コンピュータ・プログラムの動的マイグレーション
US20080196026A1 (en) * 2007-02-12 2008-08-14 Alain Charles Azagury Device, method and computer program product for executing a migrated execution context by a storage controller
JP2008217302A (ja) 2007-03-02 2008-09-18 Nec Corp 仮想マシンシステム、管理サーバ、仮想マシン移行方法及びプログラム
US20090119087A1 (en) * 2007-11-06 2009-05-07 Vmware, Inc. Pass-through and emulation in a virtual machine environment
JP2010117760A (ja) 2008-11-11 2010-05-27 Hitachi Ltd 仮想マシン移動管理サーバおよび仮想マシン移動方法
JP2010244524A (ja) * 2009-03-17 2010-10-28 Hitachi Ltd 仮想サーバの移動方法の決定方法及びその管理サーバ
JP2011008780A (ja) * 2009-06-25 2011-01-13 Vmware Inc 仮想インフラストラクチャを用いた情報技術リスク管理

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2690553A4 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015001827A (ja) * 2013-06-14 2015-01-05 日本電信電話株式会社 管理装置、管理方法、管理プログラムおよび通信システム

Also Published As

Publication number Publication date
EP2690553A1 (en) 2014-01-29
US20140019974A1 (en) 2014-01-16
JP5804050B2 (ja) 2015-11-04
EP2690553A4 (en) 2016-06-15
US9244731B2 (en) 2016-01-26
JPWO2012127633A1 (ja) 2014-07-24

Similar Documents

Publication Publication Date Title
JP5804050B2 (ja) 移動管理装置、移動管理方法および移動管理プログラム
JP5401922B2 (ja) 仮想システム制御プログラム、方法及び装置
JP5285353B2 (ja) 複数のサービス構成要素に対応するアクションの実行を管理するためのコンピュータ・システム、並びにその方法及びコンピュータ・プログラム
JP5239075B2 (ja) 複数のサービスステップを含むサービスプロセスを管理するためのコンピュータ・システム、並びにその方法及びコンピュータ・プログラム
JP5352890B2 (ja) 計算機システムの運用管理方法、計算機システム及びプログラムを記憶する計算機読み取り可能な媒体
JP5803496B2 (ja) ストレージシステム
JP2013196206A (ja) アクセラレータ管理装置、アクセラレータ管理方法および入出力装置
CN110520844A (zh) 云管理平台、虚拟机管理方法及其系统
JP2016508349A (ja) クラスタ境界にわたるサービス移行
WO2015198440A1 (ja) 管理サーバ、計算機システム及び方法
JP2018026042A (ja) 移動制御プログラム、移動制御装置及び移動制御方法
JP2005309479A (ja) 電子配付物の配付制御システム及び方法
JP2015132887A (ja) 要求分散プログラム、要求分散方法および情報処理装置
JP2014109900A (ja) データセンタ，データセンタでのシステムの複写サービスの提供方法及びデータセンタでのシステムの複写プログラム
EP3516517A1 (en) Service location management in computing systems
Cao et al. Cluster as a service: A resource sharing approach for private cloud
JP5725191B2 (ja) 電源管理装置、電源管理方法および電源管理プログラム
WO2014049854A1 (ja) 計算機システム、及びプログラム
JP2015103094A (ja) 仮想リソース管理装置、選択方法及び選択プログラム
JP2011100263A (ja) 仮想コンピュータシステム、仮想コンピュータ管理方法および管理プログラム
US11818000B2 (en) Continuous delivery of management configurations
JPWO2017002185A1 (ja) サーバストレージシステムの管理システム及び管理方法
JP6278938B2 (ja) ストレージ管理装置、ストレージ管理方法、及び、プログラム
TW202031016A (zh) Ict資源管理裝置、ict資源管理方法以及ict資源管理程式
JP2012141698A (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: 11861444

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2013505703

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE