JP2005135137A - Virtual computer system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To unitarily deal with a command executed with a guest OS on each virtual computer in a virtual computer system. <P>SOLUTION: The command of an operating system working on the virtual computer can be entered on a control screen displayed by a hypervisor of the virtual computer system. In the control screen, the command and the identifier of each virtual computer executing it are entered as a pair, thereby performing the setting/change of the command and the execution conditions. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to a virtual machine system, and more particularly to a virtual machine system that provides a user interface suitable for handling commands executed by an operating system on a virtual machine.

  In the conventional virtual machine system, when the virtual machine is handled, the screen is switched on the console, and an input operation is performed on the window of the operating system (hereinafter referred to as “guest OS”) of each virtual machine.

  For example, Patent Literature 1 below discloses a technique for exclusively displaying each screen of a virtual machine.

JP 2002-318699 A

  In the prior art described above, there is a problem that the user has to switch screens one by one in order to input a command to be executed by the guest OS of each virtual machine, and a troublesome operation is necessary. In particular, this inconvenience becomes more pronounced as the number of virtual machines that can be handled by the virtual machine system increases.

  Further, in the prior art interface, since the commands executed in the guest OS of each virtual machine are independent, it is difficult to execute the commands of a plurality of guest OSs at the same time. For example, when measuring the performance of the entire virtual machine system, it is necessary to simultaneously execute a plurality of guest OS commands and apply the same load. In the prior art, it is difficult to align the command execution start times at such times.

  In addition, in the command that waits for the next processing until the user responds to the message output from the guest OS, the means for centrally controlling the response of the plurality of guest OSes and the user is not considered. A user's response is required for each message of the guest OS at the time of execution. Also, there is a problem in that guest OSs on other LPARs cannot be controlled according to the execution results of guest OSs on a certain LPAR.

  The present invention has been made to solve the above-described problems, and an object of the present invention is to provide a virtual machine that can handle commands executed by the guest OS on each virtual machine in a unified manner from a control screen displayed by the hypervisor. To provide a system.

  It is another object of the present invention to provide a virtual machine system capable of performing automatic execution of commands executed by a guest OS on a virtual machine and cooperation between virtual machines.

  In the virtual computer system of the present invention, an operating system that distributes resources of the real computer of each virtual computer, prepares a control screen unique to the hypervisor that controls each virtual computer, and operates on the virtual computer there To be able to enter commands.

  On this control screen, a command and an identifier of each virtual machine on which the command is executed are input as a pair, and the command and its execution condition can be set / changed.

  The hypervisor stores the input command and its execution condition in the storage area, transfers it to the input buffer, and causes the guest OS of each virtual machine to execute it. The guest OS message after the command execution is transferred to the output buffer and displayed on the guest OS screen of the virtual machine.

  In addition, the response to the message after the command execution of the guest OS of the virtual machine is stored in advance, and the hypervisor returns the stored response to the message of the guest OS of each virtual machine, thereby automatically executing the command. Make sure that the virtual machines work together.

  According to the present invention, it is possible to provide a virtual machine system that can handle commands executed by the guest OS on each virtual machine in a unified manner from the control screen displayed by the hypervisor.

  In addition, it is possible to provide a virtual machine system capable of performing automatic execution of commands executed by the guest OS on the virtual machine and cooperative operation between the virtual machines.

  Embodiments according to the present invention will be described below with reference to FIGS.

A first embodiment according to the present invention will be described below with reference to FIGS.
First, the configuration of the virtual computer system according to the present invention will be described with reference to FIGS. 1 and 2.
FIG. 1 is an overall configuration diagram of a virtual computer system according to the present invention.
FIG. 2 is a block diagram showing in detail the inside of the hypervisor.

  As shown in FIG. 1, the virtual machine system of the present invention operates on the information processing apparatus 100, the hypervisor 110, virtual machines (hereinafter referred to as LPAR (Logical Partition)) 121 to 123 controlled by the hypervisor 110, and each LPAR. Operating system (hereinafter referred to as “guest OS”) 141-143.

  The information processing apparatus 100 includes an input device 101, a display device 102, a central processing unit 103, an information storage device 104, an external storage device 105, and the like.

  The information storage device 104 is loaded with a hypervisor 110. The hypervisor 110 is a mechanism that distributes and controls hardware resources to the LPARs 121 to 123 configured on the information processing apparatus 100.

  The hypervisor 110 includes an input buffer 111, an input control device 112, an output buffer 113, an output control device 114, a control screen 115, and a storage area 116.

  The control screen 115 is a unique screen controlled by the hypervisor. One of the features of the present invention is that commands of the guest OSs 141 to 143 of the LPARs 121 to 123 and their execution conditions can be input from this control screen.

  The storage area 116 is an area for storing commands and execution conditions input from the control screen 115.

  The input buffer 111 is a buffer for passing a command to each LPAR based on the execution condition stored in the storage area 116. In FIG. 1, the input buffers 111 are described so as to be taken by the number of LPARs for each LPAR, but may be transferred to each LPAR by one input buffer 111.

  On the other hand, the output buffer 113 is an area for storing the messages of the guest OSs 141 to 143 of the LPARs 121 to 123. The message stored in the output buffer 113 is used for displaying on the control screen 115. Although this output buffer 113 is described as being taken by the number of LPARs for each LPAR, one output buffer 113 may be used.

  The input control device 112 performs control to transfer the command stored in the storage area 116 to the input buffer based on the execution condition.

  Further, the output control device 114 outputs a message stored in the output buffer 113 to the display device 102 based on the execution condition of the storage area 116.

  On each LPAR 121-123, each guest OS 141-143 is running, and when an OS command is input, it is executed according to its specifications. Each LPAR 121 includes logic input devices 131 to 133 for input and logic output devices 134 to 136 for output.

  Next, the inside of the hypervisor, in particular, the structure of the storage area will be described in detail with reference to FIG.

  The data structure of the storage area 210 in the hypervisor 200 includes an identification ID 211, a command data storage area 212, an attribute 213, a target LPARID 214, a command start time 215, and a command state 216.

  The identification ID 211 is an ID used by the hypervisor for command identification. The command data storage area 212 is an area for storing an actually input command. The attribute 213 contains an identifier used for the hypervisor to process the command. As will be described later, an identifier indicating the type of execution command, OS message, and operator response is entered in the case of control during the automatic command execution function.

  The target LPAR ID 214 is an identifier of the LPAR that executes the command.

  The command start time 215 is the start time of the command specified as the command execution condition.

  The command status is an identifier that indicates the status of the command, that is, an execution waiting status, normal termination, abnormal termination, and the like.

Next, an example of the hypervisor control screen 115 will be described with reference to FIG.
FIG. 3 is a diagram showing a Guest OS command control screen.

  This Guest OS command control screen 301 is one of the control screens 115, and is a screen for the user to input a guest OS command.

  First, as shown in FIG. 1, the user inputs a command to be executed on the guest OS in the Command filed 302 of the Guest OS command control screen 301 displayed on the display device 102. The command is exemplified by a performance measurement command.

  In the input of LPAR No. 303, the target LPAR of the input command is selected. When the target LPAR is selected, “Y” is displayed in the corresponding LPAR column. The command input 306 shows a state in which LPAR1 and LPAR2 are selected.

  In the Execute Time 304 column, the execution start time of the input command is input. Execute Time 304 consists of year, month, day, hour, and minute. In this example, the command input 306 specifies June 13, 2003, 22:30.

  Status 305 is a column indicating the status of the command. In the command input 306, “Pending” is displayed indicating that it is in a waiting state.

  Next, the operation until command execution of the virtual machine system according to the first embodiment of the present invention will be described with reference to FIG.

  FIG. 4 is a flowchart showing operations up to command execution of the virtual machine system according to the first embodiment of the present invention.

  First, the user inputs a guest OS command, a target LPAR, and an execution start time from the Guest OS command control screen 301 shown in FIG. 3 (step 401).

  The hypervisor checks the validity of the input data (step 402).

  Then, when the date / time that does not actually exist or the date / time in the past is specified by mistake, the user is prompted to input again (step 402 NG).

  If there is no problem with the input data (step 402 OK), the input command and execution conditions are stored in the storage area (step 403). At this time, a unique identification ID is assigned to the header, the command is set in the command data storage area, the command attribute is set to “execution command”, the command state is set to “Pending”, and the input execution start time is stored. (Step 403).

  The input control device 112 compares the time obtained from the timer function of the information processing device 100 with the command start time 215 in the storage area 116, and when the designated time comes (YES in step 404), the input control device 112 sets the target LPARID 214 in the storage area 115. As a result, the information stored in the command data area is registered in the input buffer of the corresponding LPAR (step 405).

  Based on the target LPAR ID 214 in the storage area 211, the input control device stores command data from the input buffer 111 of the relevant LPAR in the logical input devices 131 to 133 of the relevant LPAR (step 406), and interrupts the guest OS of the relevant LPAR. (Step 407).

  The guest OS acquires input data stored in the logical input device in response to the interrupt (step 408).

  Then, the guest OS checks the validity of the input command (step 409). If the command is invalid (step 409 NG), a message is output, the command status 216 in the storage area 116 is set to “abnormal termination”, and the process is terminated (step 415).

  If there is no problem with the validity check of the input command (step 409 OK), the guest OS of the target LPAR executes the command (step 410).

  Then, the guest OS message generated by executing the command is stored in the logical output devices 134 to 136 (step 411).

  Next, the output control device 114 of the hypervisor 110 stores the information of the logic output devices 134 to 136 in the output buffer of the corresponding LPAR (step 412). Then, the command state 216 in the storage area 116 is set to “normal end” (step 413).

  The message information in the output buffer is output on the screen displayed by the LPAR on the display device 102 when the user selects an arbitrary LPAR (step 414).

  A second embodiment according to the present invention will be described below with reference to FIGS.

  The present embodiment is an example of a virtual machine system having a function of automatically executing a command of each LPAR without a user response.

  FIG. 5A and FIG. 5B are examples when installing an application such as a compiler that runs on the guest OS, and are examples of user responses to messages from the guest OS.

  First, the user inputs a compiler installation execution command 502. This example is a C ++ compiler.

Then, the guest OS displays a message 505 and requests the user to input one of “1, 2, x”.

  Reference numeral 503 responds to the question of the guest OS. Here, the user selects 1, Enter key.

  Reference numeral 506 denotes a guest OS display message. Here, it is shown that the process proceeds to the next process by pressing Enter.

  In 504, the user selects the Enter key.

  Reference numeral 606 denotes a display message of the guest OS. 0 The guest OS requests the user to select “accept” or “reject”.

  At 602, the user has selected the accept and Enter keys.

  In 607, the guest OS asks the user about the installation destination directory.

  In 603, the user selects the / opt / intel, Enter key.

  At 608, the guest OS asks the user for rpm options.

  At 604, the user has selected the option of -U--replies files and Enter key for rpm.

In 609, the guest OS requests the user to input any one of 1, 2, 3, 4, and X. In 605, the user selects the X and Enter keys.

  As described above, there is a case where a response is requested from the user by executing a command of the guest OS. In the conventional virtual machine system, the LPAR guest OS screen on the display device 102 is switched using the hardware key or the like for the target LPAR, and the user responds to the guest OS message on the screen. Was entered.

  When a plurality of LPARs exist and it is desired to perform the same processing, the user has to perform the same operation in all necessary LPARs.

  In this embodiment, there is provided means for eliminating such annoyance and automatically executing a command without a user's response.

Next, an Auto Operating control screen 701 for automatic command execution will be described with reference to FIG.
FIG. 6 is a diagram showing an Auto Operating control screen 701.

  The Auto Operating control screen 701 is one of the control screens of the hypervisor 110, and is a screen on which a user inputs information for automatically executing a command.

  The user selects the target LPAR number using LPAR No. 702.

  In the input area 704, information for automation is input.

  Status 703 is a column in which the hypervisor displays the current state of the command. For example, “Done” means that the process is finished, and “Pending” means that the process is waiting to be executed.

  The execution start time Execute Time 705 is a time at which the command 704 is started. Execute Time 705 is composed of year, month, day, hour, and minute.

  By defining execution commands, OS messages, and user responses in advance on the Auto Operating control screen 701, the conventional operations shown in FIGS. 5A and 5B can be automated.

  7A and 7B are flowcharts for explaining the command automatic execution operation of the virtual machine system according to the second embodiment of the present invention.

  First, the user inputs the target LPAR, execution command, OS message, user response, and execution start time on the Auto Operating control screen 701 shown in FIG. 6 (step 801).

  The hypervisor checks the validity of the input data (step 802).

  Then, when the date / time that does not actually exist or the past date / time is specified by mistake, the user is prompted to input again (step 802 NG).

  If there is no problem with the input data (step 802 OK), the input command and execution condition are registered in the storage area (step 803). At this time, a unique identification ID is assigned to the header portion, and the input execution command, OS message, and user response are stored in the command data storage area. The attribute 213 is classified and set as an execution command (E :), an OS message (M :), and a user response (R :), the execution start time is stored, and the command execution state is set to the “Pending” state. To do.

  The input control device 112 compares the time obtained from the timer function of the information processing device 100 with the command start time of the storage area, and when the designated time comes (YES in step 804), looks at the target LPARID 214 in the storage area 116. Then, the command stored in the command data storage area 212 is registered in the input buffer of the corresponding LPAR (step 805).

  The input control device 112 stores command data from the input buffer of the relevant LPAR obtained from the target LPAR ID 214 in the storage area 116 in the logical input devices 131 to 133 of the relevant LPAR (step 806), and interrupts the guest OS of the relevant LPAR. (Step 807).

  The guest OS acquires the input data stored in the logical input devices 131 to 133 in response to the interruption (step 808).

  The guest OS then checks the validity of the entered command (step 809). If the command is invalid (step 809 NG), a message is output, the command status of the storage area is set to “abnormal termination”, and the process is terminated (step 814). If there is no problem in the validity check of the input command (step 809 OK), the guest OS of the target LPAR executes the command (step 810).

  Then, the guest OS message generated by executing the command is stored in the logical output devices 134 to 136 (step 811).

  The output control device 114 stores the guest OS messages of the logical output devices 134 to 136 in the output buffer of the corresponding LPAR (step 812). The command status in the storage area is set to “normal end” (step 813).

  Next, the output control device 114 checks whether or not there is an execution waiting command in the storage area 116 (FIG. 7B, step 901).

  If it does not exist, the process ends (step 904).

  If it exists, the output control device 114 compares the output buffer 113 with the command data storage area 212 in the storage area and checks whether there is the same guest OS message (step 902).

  If it does not exist, the process ends (step 905).

  If it exists, the process returns to step 805 in FIG. 7A, and the output control device 114 stores the user response corresponding to the message in the input buffer 111.

  In the above, by defining commands, OS messages, and user responses in the Auto Operating control screen 701, the virtual computer system that automatically executes the commands executed in each LPAR without any user response. Have said.

  With the configuration of the virtual machine system according to the second embodiment, it is possible to select an LPAR and perform a cooperative operation between the LPARs.

  For example, when an LPAR1 command output message is output, a series of operations can be performed between different LPARs, such as executing a command in LPAR2. This cooperative operation can also be used for performance measurement for each LPAR.

1 is an overall configuration diagram of a virtual computer system according to the present invention. It is the block diagram which showed the inside of the hypervisor in detail. It is a figure which shows Guest OS command control screen. It is a flowchart which shows operation | movement until command execution of the virtual machine system which concerns on 1st Example of this invention. This is a response example when a compiler installation execution command is input on the screen 501 on the guest OS of each LPAR (part 1). This is a response example when a compiler installation execution command is input on the screen 501 on the guest OS of each LPAR (part 2). It is a figure which shows the Auto Operating control screen. It is a flowchart explaining the operation | movement of the command automatic execution of the virtual machine system which concerns on 2nd Example of this invention (the 1). It is a flowchart explaining the operation | movement of the command automatic execution of the virtual machine system which concerns on 2nd Example of this invention (the 2).

Explanation of symbols

  DESCRIPTION OF SYMBOLS 100 ... Information processing apparatus, 101 ... Input device, 102 ... Display device, 103 ... Central processing unit, 104 ... Memory, 105 ... External storage device, 110 ... Hypervisor, 111 ... Input buffer, 112 ... Input control device, 113 ... Output Buffer 114, output control device 115, control screen 116, storage area 121, virtual machine 1, 122, virtual machine 2, 123 virtual machine n, 131 logical input device 1 132 logical input device 2 133 ... Logical input device n, 134 ... Logical output device 1, 135 ... Logical output device 2, 136 ... Logical output device n, 141 ... Guest OS1, 142 ... Guest OS2, 143 ... Guest OSn.

Claims (5)

In a virtual machine system that builds a virtual machine on a computer and controls each virtual machine with a hypervisor,
Means for displaying a control screen for inputting a command of an operating system operating on the virtual machine;
Means for executing a command input from the control screen on the virtual machine.   2. The virtual computer system according to claim 1, further comprising: means for setting / changing the command and its execution condition from the control screen; and means for displaying the execution status of the command on the control screen. In a virtual machine system that builds a virtual machine on a computer and controls each virtual machine with a hypervisor,
Means for inputting an operating system command operating on the virtual machine and its execution condition from a control screen displayed on a display device;
Means for storing the input command and the execution condition in a storage area in the hypervisor;
Means for causing the virtual computer to execute a command stored in the storage area in accordance with an execution condition thereof.   An operating system output message on the virtual machine, means for preliminarily storing information related to a response thereto, and means for executing a command executed on the virtual machine without a user response. The virtual computer system according to claim 1.   5. The virtual machine system according to claim 4, further comprising means for executing a command executed by an operating system on another virtual machine based on an output message of an operating system on a virtual machine.

Images