JP2012243096A - Guest os management device, guest os management method, and guest os management program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To efficiently use a memory area.SOLUTION: A guest OS management device executes the steps of: monitoring an operating condition of each guest OS that shows an OS which operates on a virtual machine built on the guest OS management device; making the guest OS sleep when the monitored condition satisfies predetermined conditions; saving a memory page of the guest OS, which is made to sleep, and then releasing it; when finding that a packet arrives at the sleeping guest OS, resuming the corresponding guest OS, and retrieving and expanding the released memory page.

Description

  The present invention relates to a guest OS management device, a guest OS management method, and a guest OS management program.

  Conventionally, there is a virtualization technology for starting a plurality of operating systems (OSs) on one physical machine. Here, the plurality of OSs may be referred to as guest OSs. In such a virtualization technique, when a plurality of guest OSs are activated, the virtual machine monitor makes it appear as if the guest OS virtually occupies a limited number of computer resources. Thereby, in the virtualization technology, each guest OS can be operated without any special change.

  In addition, the virtual machine monitor adjusts a use request for a computer resource that each guest OS seems to occupy, and shares the computer resource so that the guest OS does not interfere with the computer resource. Specifically, taking physical memory as an example of a computer resource, the virtual machine monitor can start 16 guest OSs when allocating 256 GB of physical memory to each guest OS. It becomes.

  However, while the amount of memory allocated to each guest OS is guaranteed to be occupied by each guest OS at the time of startup, it is difficult for the guest OS to increase or decrease the amount of memory after startup. . In other words, each guest OS cannot increase the amount of memory even when there are many processes, and must occupy the amount of memory allocated at startup even when there are few processes.

  For these reasons, there is a demand for efficient use of computer resources of physical machines and for operating more guest OSes on one physical machine. For this reason, recently, there is an overcommitment technology that allows each guest OS to use more memory than the physical memory that the physical machine actually has. Such an overcommitment technique can be realized by a technique such as sharing the same memory page, ballooning, or swapping as one aspect.

  The technology for sharing the same memory page is, for example, by scanning the memory page used by each guest OS and detecting the memory page with the same content, merging the memory pages with the same content, Is a technology to release In such a technique, when writing or the like occurs in the merged memory page and the contents are not the same, the memory page is duplicated, and writing is performed on the duplicated memory page.

  The ballooning technique is, for example, a technique in which software called a balloon driver is operated in a guest OS, and a memory page on the guest OS free list is returned to the virtual machine monitor side. In such a technique, the returned memory page is passed to the free list of another guest OS that is struggling with memory, so that a memory page is transferred from a guest OS with a small memory usage to a guest OS with a large memory usage. Be flexible.

  For example, when the memory is tight, the swapping technique selects a memory page with low usage frequency based on an LRU (Least Recently Used) algorithm or the like, and saves the selected memory page in a secondary storage area such as a disk area. Technology. With this technique, the memory page saved in the secondary storage area is deleted from the physical memory and becomes a free page.

“Understanding Memory Resource Management in VMware ESX 4.1”, [online], [searched on May 9, 2011], Internet <http://www.vmware.com/files/pdf/techpaper/vsp_41_perf_memory_mgmt.pdf>

  However, the conventional technique has a problem that the memory area cannot be used effectively. For example, the guest OS executes an idle process even when there is no process to process. Further, for example, a periodic event such as a timer interrupt may be generated to adjust the time in the guest OS. That is, it is preferable to always keep at least a part of memory pages on the memory even for a guest OS that is not being processed. These things can happen as well using various over-commitment technologies.

  For example, since the technology for sharing the same memory page is a page that is always written or a memory page that does not have the same memory page, it exists on the memory as a single memory page without being merged. Not all memory pages can be merged. In addition, for example, ballooning and swapping techniques, when memory pages that are frequently accessed are returned or saved, frequent memory page exchanges between guest OSs and thrashing in which memory pages move between the secondary storage area and the memory Occurs. As a result, in the conventional technique, more guest OSs are operated on one physical machine by the overcommitment technique, but the memory area is not always effectively used.

  Therefore, the present invention has been made in view of the above, and an object of the present invention is to provide a guest OS management device, a guest OS management method, and a guest OS management program capable of effectively using a memory area. To do.

  In order to solve the above-described problems and achieve the object, the guest OS management device according to the present invention monitors a status related to the operation of the guest OS indicating the OS operating on the virtual machine constructed on the own device. And a sleep unit that causes the guest OS to sleep when a situation monitored by the monitoring unit satisfies a predetermined condition, and a memory control unit that releases and then releases the memory page of the guest OS that has been caused to sleep by the sleep unit. Have

  According to one aspect of the guest OS management device, guest OS management method, and guest OS management program according to the present invention, there is an effect that the memory area can be used effectively.

FIG. 1 is a diagram illustrating a system configuration example of the virtualization technology according to the first embodiment. FIG. 2 is a diagram illustrating a configuration example of the physical machine according to the first embodiment. FIG. 3 is a diagram illustrating an example of functional blocks of the guest OS management apparatus according to the first embodiment. FIG. 4 is a diagram illustrating a system configuration example including the function of the guest OS management apparatus. FIG. 5 is a flowchart illustrating an example of the flow of the sleep process according to the first embodiment. FIG. 6 is a flowchart illustrating an example of a resume process according to the first embodiment. FIG. 7 is a diagram showing that the processing by the guest OS management program is specifically realized using a computer.

  Embodiments of a guest OS management apparatus, a guest OS management method, and a guest OS management program according to the present invention will be described below with reference to the accompanying drawings. In addition, this invention is not limited by the following examples.

[Virtualization system configuration]
The system configuration of the virtualization technology according to the first embodiment will be described with reference to FIG. FIG. 1 is a diagram illustrating a system configuration example of the virtualization technology according to the first embodiment.

  For example, as illustrated in FIG. 1, the system configuration of the virtualization technology includes a physical machine that configures a virtual machine including a plurality of guest OSs, and a client that can be connected to the physical machine via a network. In the above configuration, as one aspect, each virtual machine operates with a service request from the client as a trigger, and provides a specific service to the client via the network. The physical machine is an information processing apparatus such as a PC (Personal Computer) or a server apparatus. Moreover, the number of each apparatus is not restricted to the number of illustration.

[Physical machine configuration]
Next, the configuration of the physical machine according to the first embodiment is described with reference to FIG. FIG. 2 is a diagram illustrating a configuration example of the physical machine according to the first embodiment.

  For example, as illustrated in FIG. 2, the physical machine includes at least one virtual machine including a guest OS that operates software for providing a service (server service) to a client. On the physical machine, virtual machine management software including a virtual machine monitor, a hypervisor, or a host OS operates. The virtual machine monitor is software for operating a plurality of guest OSes, for example. One or more guest OSs operate on the virtual machine. The hypervisor is a control program for realizing a virtualization technology, for example. The host OS refers to an OS installed on a physical machine, for example.

  The physical machine has real hardware such as a physical memory, a disk, a network card (NIC), and a CPU (Central Processing Unit). The physical memory is a storage device that is used as a main memory in a physical machine, for example. The disk is a storage device that records data on an arbitrary storage medium, for example. For example, the network card transmits / receives a packet to / from a client or the like via the network. The CPU is, for example, an electronic circuit that controls the entire physical machine. Further, the physical memory and the disk have a secondary storage area. The use of the secondary storage area will be described later.

[Guest OS management device configuration]
Next, functional blocks of the guest OS management apparatus according to the first embodiment are described with reference to FIG. FIG. 3 is a diagram illustrating an example of functional blocks of the guest OS management apparatus according to the first embodiment.

  For example, as illustrated in FIG. 3, the guest OS management device 100 includes a monitoring unit 110, a sleep unit 120, a memory control unit 130, and a resume unit 140. Each function of the guest OS management apparatus 100 is included in the physical machine shown in FIG. 1 or 2 as one aspect. Alternatively, as shown in FIG. 4, a part of the functions of the guest OS management apparatus 100 can be provided on another physical machine (network apparatus). FIG. 4 is a diagram illustrating a system configuration example including the functions of the guest OS management apparatus 100.

  Further, a plurality of physical machines on which the virtual machine management software is operated with the configuration shown in FIG. 2 are operated, and operate on each physical machine on which the virtual machine management software operates on another physical machine connected via the network. Send the usage status of each guest OS computer and the occurrence status of each event, determine whether to sleep or resume each guest OS on the physical machine that received the information, and put it to sleep, or If it is determined to resume, the command can be transmitted to the physical machine on which the virtual machine management software operates.

  The monitoring unit 110 monitors the status related to the operation of the guest OS indicating the OS that operates on a virtual machine that is another virtual computer environment built on the guest OS management apparatus 100. Examples of such computer resources include physical memory, disk, network card, CPU, and the like. That is, the monitoring unit 110 monitors the use status of computer resources when access to a memory page or the like is executed as one aspect. In addition, the monitoring unit 110 notifies the sleep unit 120 of the monitoring status. Further, as one aspect, when monitoring a network packet or the like, the monitoring unit 110 arranges the monitoring unit 110 on another physical machine (network device) connected via a network, and the physical machine has other functions. May be allowed.

  For example, the monitoring unit 110 may monitor the occurrence state of a predetermined event of the guest OS. When monitoring the occurrence status of a predetermined event, the monitoring unit 110 may be disposed in each guest OS, for example. Examples of such a predetermined event include process / thread creation / disappearance, file access, packet transmission / reception, exception occurrence, number of open or closed sockets, event that changes the state of the guest OS, and the like. That is, the monitoring unit 110 monitors the occurrence of a predetermined event when access to a memory page or the like is executed as one aspect. Similarly, at this time, the monitoring unit 110 notifies the sleep unit 120 of the monitoring status.

  The sleep unit 120 causes the guest OS to sleep when the status monitored by the monitoring unit 110 satisfies a predetermined condition. Such predetermined conditions are stored in, for example, a storage unit (not shown). More specifically, an example of monitoring the usage status of the computer resource will be described below. The sleep unit 120 corresponds to a corresponding guest OS when the usage status of the predetermined computer resource monitored by the monitoring unit 110 is less than or equal to a predetermined condition. Sleep. That is, the sleep unit 120 determines that the service request is not being processed because the computer resource is not used, and sleeps the guest OS that may use the memory area in some form such as execution of an idle process. . As a result, memory access or the like by the guest OS that has been put to sleep can be stopped. In addition, the sleep unit 120 notifies the memory control unit 130 of the guest OS that has been put to sleep.

  Specifically, the guest OS management device 100 stores the CPU usage rate, the memory usage rate, the network usage rate, etc. in any guest OS when processing for a service usage request is not being executed, and each computer One or more values of resources are set as a reference value. The sleep unit 120 responds to a service request from a client in the corresponding guest OS when the usage state is equal to or less than a reference value for a predetermined period based on the monitoring of the computer resource by the monitoring unit 110. It is determined that the process is not executed, and the corresponding guest OS is put to sleep.

  Further, the example of monitoring the occurrence status of the predetermined event will be described in detail. The sleep unit 120 is configured to output a corresponding guest when the occurrence status of the predetermined event monitored by the monitoring unit 110 is equal to or less than a predetermined condition. Sleep the OS. That is, the sleep unit 120 determines that the service request is not being processed because no event has occurred, and sleeps the guest OS that may use the memory area in some form such as execution of an idle process. That is, the virtual machine management software illustrated in FIG. 2 causes the corresponding guest OS to sleep based on the monitoring result from the monitoring unit 110. As a result, memory access or the like by the guest OS that has been put to sleep can be stopped. Similarly, at this time, the sleep unit 120 notifies the memory control unit 130 of the guest OS that has been put to sleep.

  Here, an OS that provides a Web service in which a homepage is constructed on an HTTP (HyperText Transfer Protocol) server such as Apache (registered trademark) and returns the homepage in response to an HTTP request from a client will be described as an example. Such Apache (registered trademark) employs a model in which a thread is generated in response to a request from a client and the thread processes the request from the client. Thereby, when the thread is not executed on the guest OS, it can be determined that the request from the client is not processed.

  Therefore, the sleep unit 120 corresponds to the case where no thread generation from Apache (registered trademark) is observed for a certain period based on the monitoring of the thread generated on the guest OS by the monitoring unit 110. The guest OS determines that the request from the client is not processed, and sleeps the corresponding guest OS. Further, not only the thread but also the process generated in the guest OS, the number of open sockets, and the like may be set to sleep based on information that can be acquired from the guest OS.

  The memory control unit 130 saves and releases the memory page of the guest OS that has been put to sleep by the sleep unit 120. For example, the memory control unit 130 moves the memory page of the guest OS that has been put to sleep by the sleep unit 120 to the secondary storage area, and releases the memory page of the guest OS. Such a secondary storage area indicates, for example, a physical memory, a disk area, or the like. In the physical memory, a specific area can be used as a secondary storage area, and this area can be used as a compressed memory area. That is, the secondary storage area may refer to a compressed memory area provided on the physical memory.

  The resume unit 140 resumes the guest OS when the occurrence of a specific event for the guest OS that has been put to sleep by the sleep unit 120 is detected, reads the memory page released by the memory control unit 130, and expands it To do. Examples of such specific events include the arrival of a packet and the passage of a certain time.

  For example, when the monitoring unit 110 detects that a packet for a guest OS that has been put to sleep by the sleep unit 120 has arrived, the resume unit 140 resumes from the sleep state to the active state by resuming the corresponding guest OS. Transition. Here, the guest OS management device 100 stores the destination IP (Internet Protocol) address and / or port number of the packet in association with the guest OS in a storage unit (not shown), and each guest OS. Are managed (sleep state or active state). Using these pieces of information, when the monitoring unit 110 detects that a packet for the guest OS has arrived, the resume unit 140 determines whether or not the guest OS that is the transmission destination of the packet is in a sleep state. doing. Then, the resume unit 140 reads the memory page moved to the secondary storage area by the memory control unit 130 and restores it on the memory. As a result, the arriving packet is passed to the resumed guest OS for processing. Note that when the guest OS that is the packet transmission destination is in the active state, the resume unit 140 transfers the packet as it is.

  As another example, when the resume unit 140 sets a timer when the sleep unit 120 causes a guest OS to sleep, the timer expires and it is determined that a predetermined time has elapsed. In addition, the corresponding guest OS can be resumed and transition from the sleep state to the active state can be performed.

[Flow of sleep processing]
Next, the sleep process according to the first embodiment will be described with reference to FIG. FIG. 5 is a flowchart illustrating an example of the flow of the sleep process according to the first embodiment. Note that the sleep processing mainly refers to processing by the monitoring unit 110, the sleep unit 120, and the memory control unit 130.

  For example, as shown in FIG. 5, the guest OS management apparatus 100 monitors the status related to the operation of the guest OS (step S101). Regarding the status related to the operation of the guest OS, for example, the usage status of computer resources such as physical memory, a disk, a network card, and a CPU, creation / disappearance of processes or threads, file access, packet transmission / reception, occurrence of exception, open The number of sockets that are closed and the occurrence status of a specific event such as an event that changes the state of the guest OS.

  Then, the guest OS management device 100 determines whether or not the monitored situation satisfies a predetermined condition (step S102). For the predetermined condition, the guest OS management device 100 determines whether the usage status for a certain period is equal to or less than the predetermined condition (a constant value) when monitoring the usage status of the computer resource, and determines the occurrence status of the specific event. In the case of monitoring, it is determined whether or not the occurrence state for a certain period is below a predetermined condition (a certain value).

  At this time, when the guest OS management device 100 determines that the monitored status satisfies the predetermined condition (Yes in step S102), the guest OS management device 100 sleeps the corresponding guest OS (step S103). On the other hand, when the guest OS management apparatus 100 determines that the monitored situation does not satisfy the predetermined condition (No at Step S102), the guest OS management apparatus 100 executes the process at Step S101 again because the corresponding guest OS is active. Thereafter, the guest OS management device 100 moves the memory page used by the guest OS that has been put to sleep to the secondary storage area, and releases the memory (step S104).

[Resume processing flow]
Next, the resume process according to the first embodiment will be described with reference to FIG. FIG. 6 is a flowchart illustrating an example of a resume process according to the first embodiment. The resume process mainly refers to a process performed by the resume unit 140.

  For example, as illustrated in FIG. 6, when the guest OS management device 100 detects that a packet for the guest OS has arrived (Yes in step S201), whether the guest OS that is the destination of the packet is in a sleep state or not. Is determined (step S202). At this time, the guest OS management device 100 resumes the corresponding guest OS when the guest OS that is the transmission destination of the packet is in the sleep state (Yes in step S202) (step S203).

  Then, the guest OS management device 100 reads the memory page of the guest OS that has been in the sleep state, and restores it to the memory (step S204). Thereafter, the guest OS management device 100 transfers the packet to the resumed guest OS (step S205). In addition, when the guest OS management device 100 does not detect that a packet for the guest OS has arrived (No in step S201), the guest OS management device 100 enters a state of waiting for arrival of a packet. In addition, when the guest OS to which the packet is transmitted is not in the sleep state (No at Step S202), the guest OS management apparatus 100 transfers the packet to the guest OS that is operating (Step S206).

[Effects of Example 1]
The guest OS management device 100 sleeps a guest OS that is not being used based on the use status of a computer resource or the occurrence of an event in the guest OS, and saves and releases the memory page of the guest OS that has been put to sleep. As a result, the guest OS management device 100 can use the memory area more effectively than in the conventional technology in which the guest OS that is not used occupies the memory.

  The embodiments of the guest OS management 100 according to the present invention have been described so far. However, the embodiments may be implemented in various different forms other than the embodiments described above. Therefore, different embodiments will be described in (1) monitoring target, (2) sleep priority, (3) sleep condition, (4) memory release, (5) configuration, and (6) program.

(1) Monitoring target In the above embodiment, the case where the guest OS is caused to sleep by monitoring the resource usage state of the computer and the case where the guest OS is caused to sleep by monitoring the event occurrence state have been described. The guest OS may be put to sleep when monitored and when both sleep conditions or at least one of the sleep conditions is satisfied. As a result, the number of monitoring targets is increased and the guest OS is put to sleep, so the memory area can be used more effectively.

(2) Sleep Priority In the above embodiment, the case where the necessity determination of sleep is executed independently for each guest OS has been described. The present invention is not limited to this. For example, when the memory of the entire physical machine is monitored and a memory of a certain value or more is used, or a memory of a certain value or more is used for a predetermined period. The above embodiment may be executed when the situation continues. Specifically, the monitoring unit 110 always monitors the use status of computer resources, and does not sleep the guest OS even when the monitor status of the computer resources used by a certain guest OS satisfies a predetermined condition. The current status is stored, and the execution of the guest OS is continued. In addition, when the usage status of the physical memory of the physical machine becomes a certain value or more, the sleep unit 120 sleeps those that satisfy the sleep condition based on the stored usage status of the computer resources. As a result, the processing load can be reduced, and the memory area can be used effectively without releasing the memory more than necessary.

  Further, for example, when the usage amount of a specific computer resource exceeds a predetermined reference value, a predetermined priority order among guest OSs or a group in which one or more guest OSs are grouped is determined. On the basis of the priority, the computer resource may be put to sleep until the usage amount of the computer resource becomes a predetermined value or less. Specifically, when the usage status of the physical memory becomes a certain value or more and the guest OSs are sequentially put to sleep, a priority is set in advance for each guest OS or for each group of guest OSes. Based on this priority, the guest OSs that satisfy the sleep condition are made to sleep in order from the lowest priority until the usage state of the physical memory falls below a certain value. As a result, the memory area can be used effectively without stopping the guest OS corresponding to a more important service more than necessary.

(3) Sleep conditions In the above embodiment, the case where the guest OS is set to sleep is not specifically set individually, but is common to all guest OSes. However, different conditions are set for each guest OS. Alternatively, guest OSs may be grouped and different conditions may be set for each group. As a result, it is possible to realize sleep of the guest OS according to service usage, relevance, importance, and the like.

(4) Release of memory In the above embodiment, the case where the memory page of the guest OS that has been put to sleep is moved to the secondary storage area by the memory control unit 130 has been described. However, virtual machine management software (host OS or virtual machine) You may make it move to a secondary storage area by the function of a monitor. Further, the development of the memory after the resume may be executed by the function of the virtual machine management software (host OS or virtual machine monitor). That is, when the guest OS sleeps, as one aspect, memory access does not occur in the memory area used by the guest OS, and the host OS side recognizes it as an inactive memory. When the memory of the host OS becomes tight, a mechanism related to memory management of the host OS pages out inactive memory. As a result, it is not necessary to explicitly page all memory pages at the same time as resuming. Thereby, it can be made to process suitably according to embodiment and the required performance which apply this invention.

(5) Configuration In addition, regarding the processing procedure, control procedure, specific name, information including various data and parameters, etc. (for example, names of the sleep unit 120 and the resume unit 140, etc.) shown in the above document and drawings It can be changed arbitrarily unless otherwise specified.

  Each component of the illustrated guest OS management apparatus 100 is functionally conceptual and does not necessarily need to be physically configured as illustrated. In other words, the specific form of distribution / integration of each device is not limited to the one shown in the figure, and all or a part thereof may be functionally or physically distributed or arbitrarily distributed in arbitrary units according to various burdens or usage conditions. Can be integrated. For example, the sleep unit 120 and the resume unit 140 may be integrated as a “guest OS control unit” that controls the sleep and resume of each guest OS operating on the physical machine.

  Each processing function performed in the guest OS management device 100 is realized in whole or in part by a CPU (Central Processing Unit) and a program that is analyzed and executed by the CPU, or wired logic. It can be realized as hardware.

(6) Program FIG. 7 is a diagram showing that the processing by the guest OS management program is specifically realized using a computer. As illustrated in FIG. 7, the computer 1000 includes, for example, a memory 1001, a CPU 1002, a hard disk drive interface 1003, a disk drive interface 1004, a serial port interface 1005, a video adapter 1006, and a network interface 1007. These units are connected by a bus 1008.

  As illustrated in FIG. 7, the memory 1001 includes a ROM (Read Only Memory) 1001a and a RAM (Random Access Memory) 1001b. The ROM 1001a stores a boot program such as BIOS (Basic Input Output System). The hard disk drive interface 1003 is connected to the hard disk drive 1009 as illustrated in FIG. The disk drive interface 1004 is connected to the disk drive 1010 as illustrated in FIG. For example, a removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1010. The serial port interface 1005 is connected to, for example, a mouse 1011 and a keyboard 1012 as illustrated in FIG. The video adapter 1006 is connected to a display 1013, for example, as illustrated in FIG.

  Here, as illustrated in FIG. 7, the hard disk drive 1009 stores, for example, an OS 1009a, an application program 1009b, a program module 1009c, and program data 1009d. That is, the guest OS management program is stored in, for example, the hard disk drive 1009 as a program module 1009c in which a command executed by the computer 1000 is described. Specifically, a monitoring procedure for executing processing similar to that of the monitoring unit 110 described in the above embodiment, a sleep procedure for executing processing similar to that of the sleep unit 120, and processing similar to that of the memory control unit 130 are executed. The hard disk drive 1009 stores a program module 1009c in which a memory control procedure and a resume procedure for executing the same processing as the resume unit 140 are described. Further, data used for processing by the guest OS management program is stored as, for example, the hard disk drive 1009 as program data 1009d. The CPU 1002 reads the program module 1009c and program data 1009d stored in the hard disk drive 1009 to the RAM 1001b as necessary, and executes a monitoring procedure, a sleep procedure, a memory control procedure, and a resume procedure.

  Note that the program module 1009c and program data 1009d related to the guest OS management program are not limited to being stored in the hard disk drive 1009, but are stored in, for example, a removable storage medium and read by the CPU 1002 via the disk drive 1010 or the like. May be. Alternatively, the program module 1009c and program data 1009d relating to the guest OS management program are stored in another computer connected via a network (LAN (Local Area Network), WAN (Wide Area Network), etc.), and the network interface 1007 May be read by the CPU 1002.

100 guest OS management device 110 monitoring unit 120 sleep unit 130 memory control unit 140 resume unit

Claims (7)

A monitoring unit for monitoring the status related to the operation of the guest OS indicating the OS (Operating System) operating on the virtual machine constructed on the own device;
A sleep unit that causes the guest OS to sleep when a situation monitored by the monitoring unit satisfies a predetermined condition;
A guest OS management apparatus comprising: a memory control unit that saves and then releases a memory page of the guest OS that has been put to sleep by the sleep unit. The monitoring unit monitors the occurrence of a specific event for the guest OS that is put to sleep by the sleep unit,
Resume unit that resumes the guest OS and reads and expands the memory page released by the memory control unit when the occurrence of a specific event detected by the sleep unit is detected by the monitoring unit. The guest OS management apparatus according to claim 1, further comprising: The monitoring unit monitors a usage status of a predetermined computer resource of the guest OS,
The guest OS management apparatus according to claim 1, wherein the sleep unit causes the guest OS to sleep when the usage status of the predetermined computer resource monitored by the monitoring unit is equal to or less than a predetermined condition. The monitoring unit monitors the occurrence of a predetermined event of the guest OS,
The guest OS management apparatus according to claim 1, wherein the sleep unit causes the guest OS to sleep when an occurrence state of a predetermined event monitored by the monitoring unit is equal to or less than a predetermined condition.   When the usage amount of a specific computer resource exceeds a predetermined reference value, the sleep unit determines a predetermined priority between guest OSes or a group in which one or more guest OSs are grouped. 5. The guest OS management apparatus according to claim 1, wherein sleep is performed until the usage amount of a computer resource becomes a predetermined value or less based on a predetermined priority order. A guest OS management method executed by a guest OS (Operating System) management device,
A monitoring step of monitoring a status related to the operation of the guest OS indicating the OS operating on the virtual machine constructed on the guest OS management device;
A sleep step of causing the guest OS to sleep when the situation monitored by the monitoring step satisfies a predetermined condition;
And a memory control step of saving and releasing the memory page of the guest OS that has been put to sleep by the sleep step.   A guest OS management program for causing a computer to function as a guest OS (Operating System) management device according to claim 1.

Images