RU2589853C1 - Method of providing collaborative operation of several hypervisors in computer system - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: method of performing more than one hypervisor in the same computer system, one of hypervisor should be carried out continuously, in which code in hypervisor, which should be carried out continuously, while other hypervisor do not require code execution in hypervisor mode; code start attempt in hypervisor mode is monitored from other hypervisor; code execution in hypervisor mode is stopped, which should be performed continuously; storing state of computer system at shutdown of code execution in hypervisor mode, which should be performed continuously; loaded state of computer system to perform code execution in hypervisor mode, which attempted to start; code is in mode of hypervisor which attempted to start; monitoring state of computer system for waiting to run code in hypervisor mode, which should be performed continuously; loaded previously stored state of computer system; launching code in hypervisor mode, which should be carried out continuously.

EFFECT: continuous execution of one of hypervisors in computer system.

1 cl, 4 dwg

Description

Technical field

The invention relates to virtualization technologies, and more particularly to systems and methods for ensuring the collaboration of several hypervisors in a computer system.

State of the art

Currently, virtualization technology is increasingly being used in a wide variety of fields: both in large data centers and on user computers. Virtualization provides the ability to run multiple operating systems on a single computer system, which allows the most complete use of available hardware resources. For example, a user can use several virtual machines to simultaneously execute a number of applications in various operating systems (OS). However, virtualization technology has become most in demand when used within large servers, for example, when providing web hosting services.

To ensure the operation of virtual machines, you must use a hypervisor that provides the ability to run virtual machines, acting as a manager or manager of virtual machines (Eng. Virtual Machine Manager, VMM). In the event that several hypervisors are present in the computer system, it is required to ensure their correct operation. The joint work of virtual machine hypervisors is ensured by their implementation: upon receipt of control, the processor mode changes temporarily and the virtual machine manager returns to its original mode at its discretion. For example, if several virtual machines of various manufacturers, such as VMWare or Citrix (Xen), are running on the Windows operating system, the scheduler will allocate time for the execution of hypervisors as for regular threads in the operating system (taking into account the priority of the threads). The hypervisor code itself correctly completes its execution after a certain time slot has elapsed (however, it is worth noting that this time slot does not coincide with what was selected by the OS scheduler). In a multi-core processor, a separate copy of the hypervisor will work on each core, but with a different context.

A number of publications also disclose the principle of managing multiple hypervisors in a system. For example, publication US 20140149980 solves the problem of diagnosing a cluster of hypervisors (when several hypervisors can run on the same computer), within which a hypervisor can be defined, the operation of which leads to degradation of performance. The publication US 20110023030 describes the possibility of transferring control from one hypervisor to another by hot migrating hardware resources and memory pages for running virtual machines (thus, migration occurs on the fly).

However, these publications do not solve the problem of implementing a constantly working hypervisor that periodically cedes control to hypervisors of virtual machines. Such a need can be justified if the hypervisor provides the operation of critical virtual machines or is designed to constantly monitor code execution in privileged mode (the so-called "kernel mode", Eng. Kernel mode).

Analysis of the prior art allows us to conclude about the inefficiency and, in some cases, the impossibility of using previous technologies, the disadvantages of which are solved by the present invention, namely, a system and method for implementing a constantly working hypervisor that periodically cedes control of virtual machine hypervisors.

Disclosure of invention

The technical result of the present invention is to ensure the continuous execution of one of the hypervisors in a computer system.

The continuous execution of one of the hypervisors is achieved by monitoring the state of the computer system in order to track attempts to run the code in hypervisor mode by other hypervisors. When such a state of a computer system is detected, the state of the computer system is saved and the execution of the hypervisor code is stopped, which must be constantly executed. After waiting for the possibility of starting the code execution in the hypervisor mode, the saved state of the computer system will be loaded to enable the correct restoration of the code execution in the hypervisor mode.

In yet another embodiment, the state of the computer system includes the state of the processor.

Brief Description of the Drawings

Additional objectives, features and advantages of the present invention will be apparent from reading the following description of an embodiment of the invention with reference to the accompanying drawings, in which:

FIG. 1 illustrates an operating system in which more than one hypervisor is running.

FIG. 2 provides a system for enforcing multiple hypervisors in a system.

FIG. 3 illustrates the method of operation of the present invention.

FIG. 4 is an example of a general purpose computer system on which the present invention may be implemented.

Description of Embodiments

The objects and features of the present invention, methods for achieving these objects and features will become apparent by reference to exemplary embodiments. However, the present invention is not limited to the exemplary embodiments disclosed below, it can be embodied in various forms. The essence described in the description is nothing more than the specific details necessary to assist the specialist in the field of technology in a comprehensive understanding of the invention, and the present invention is defined in the scope of the attached claims.

The present invention allows to solve the problem of continuous operation of one of the hypervisors in a computer system in the presence of other hypervisors during periodic operation of other hypervisors on the same processor core. In FIG. 1 shows an operating system (OS) 100 in which more than one hypervisor is operating, for example, a hypervisor 110a that needs to be kept constantly on, and other hypervisors 110b (there may be more than one). As an example of 110b hypervisors, we can cite dispatchers (monitors) of virtual machines from VMWare, VirtualBox (Oracle), or Citrix (Xen). An example of a hypervisor 110a may be a hypervisor, which requires constant execution of mission-critical virtual machines, or a hypervisor, which is necessary to ensure that a number of anti-virus operations are performed. In the standard work of hypervisors 110a and 110b, the standard task scheduler 120 will allocate time for execution to them. For example, in Windows, the scheduler works with priority management, which means the priority execution of higher priority threads. Therefore, within the framework of OS 100, where scheduler 120 is used, it is impossible to ensure the permanent operation of hypervisor 110a even with assigning it a higher priority, since sooner or later scheduler 120 will allocate a time quantum for the execution of hypervisor code 110b. Hereinafter, the execution of one of the hypervisors 110b primarily means the execution of virtual machines that operate under the specified hypervisors.

It is worth noting that the hypervisor 110a may be needed when performing antivirus operations for several reasons. Firstly, using a hypervisor, you can detect code execution at the kernel level of the OS (for example, rootkits). Secondly, a hypervisor may be required to bypass OS kernel protection, such as PatchGuard.

In FIG. Figure 2 shows the system for ensuring the execution of several hypervisors in the system. In the above diagram, the hypervisor 110a is not controlled by the scheduler 120 (unlike the hypervisors 110b), but rather is controlled by the handler 210, which monitors the state of the system 220. When the hypervisor 110b tries to start executing the code in the hypervisor mode (ring -1), the first change processor operating mode, since at this time commands will be executed that are responsible for preparing the subsequent launch of the virtual machine. For example, the directory of pages (English Page Directory), the CR3 register is completely overloaded. Another example of starting a virtual machine is the vmrun command (for VMWare). All these parameters and commands are highlighted in FIG. 2 as a state of the system 220. Handler 210 monitors changes in these parameters or the execution of commands (by intercepting them) to stop the execution of hypervisor 110a. In a particular embodiment, the processor 210 is implemented as an OS driver 100.

Consider in more detail the process of turning on and stopping the hypervisor 110a. This process contains the following steps:

a) preservation of the current state of the processor (i.e., at that time the code execution of one of the hypervisors 110b in the hypervisor mode);

b) execution of the hypervisor code 110a;

C) the definition of attempts to run the code of the hypervisor 110b;

d) restoration of the actual state of the processor from step a) for the correct execution of the instructions for enabling virtualization by the hypervisor 110b;

e) exiting the hypervisor mode and transferring control to the last instruction when executing the hypervisor code 110a.

Thus, the next hypervisor 110a thread instruction is already executing outside of the hypervisor mode, since further execution is already within the framework of another privilege ring (usually it will be ring 0).

FIG. 3 illustrates the method of operation of the present invention. At 310, the state of the system 220 is monitored (for example, using a handler 210). If at step 320 it is determined that the state of the system has changed (for example, the page directory has been overloaded or the vmrun command has been executed), then at step 330 the execution of the hypervisor 110a is stopped. It is also worth noting that at step 320, an additional check may occur, for example, from which mode CR3 register overload was called. If the register overload was called from kernel mode, then this is only a context switch, and if from user mode, you can additionally check that this, for example, is a call from a virtual machine process. Such a check allows minimizing the number of “false positives” when the hypervisor 110a is stopped, so as not to stop it unless absolutely necessary. At 340, it waits for the hypervisor 110a to start. The wait may include the following conditions:

- the run-time quantum ended, which the scheduler 120 allocated to execute one of the hypervisors 110b;

- there was a change in the state of the system 120;

- the processor 210 monitors the execution of the hypervisor 110b and receives a notification of the end of its work (for example, through the official Application Programmable Interface or API provided by the developer of the hypervisor).

If at step 350 it was determined that one of the hypervisors 110b completed execution (by checking the above conditions), then at step 360 it is restarted.

In one embodiment, the restart is implemented through a timer procedure (for example, in Windows, this can be done through a call to KeSetTimer). For example, after a predetermined time elapses (when the run time quantum has ended), the scheduler 120 determines whose code should be executed (for example, the start of the hypervisor 110a). The timer may be reset so that it can be restarted the next time that one of the hypervisors 110b is finished and the hypervisor 110a can be started.

Another example of when to stop the hypervisor 110a relates to a change in the state of the power-related system 220, for example, when entering hibernation mode. To this end, you can monitor power-related functions (Power Management event callback functions in Windows) or system variables (SYSTEMPOWERSTATE in Windows).

Another example of the need to stop the hypervisor 110a is the launch of code, which also leads to a strong change in the state of the processor, for example emulators (such as QEMU and other similar ones also used in antivirus applications). If the emulator and hypervisor 110a are part of an anti-virus product, then after the emulator is running, the latter can automatically start the hypervisor 110a.

FIG. 4 is an example of a general purpose computer system, a personal computer or server 20 comprising a central processor 21, a system memory 22, and a system bus 23 that contains various system components, including memory associated with the central processor 21. The system bus 23 is implemented as any prior art bus structure comprising, in turn, a bus memory or a bus memory controller, a peripheral bus and a local bus that is capable of interacting with any other bus architecture. The system memory contains read-only memory (ROM) 24, random access memory (RAM) 25. The main input / output system (BIOS) 26 contains the basic procedures that ensure the transfer of information between the elements of the personal computer 20, for example, at the time of loading the operating system using ROM 24.

The personal computer 20 in turn contains a hard disk 27 for reading and writing data, a magnetic disk drive 28 for reading and writing to removable magnetic disks 29, and an optical drive 30 for reading and writing to removable optical disks 31, such as a CD-ROM, DVD -ROM and other optical information carriers. The hard disk 27, the magnetic disk drive 28, the optical drive 30 are connected to the system bus 23 through the interface of the hard disk 32, the interface of the magnetic disks 33 and the interface of the optical drive 34, respectively. Drives and associated computer storage media are non-volatile means of storing computer instructions, data structures, software modules and other data of a personal computer 20.

The present description discloses an implementation of a system that uses a hard disk 27, a removable magnetic disk 29, and a removable optical disk 31, but it should be understood that other types of computer storage media 56 that can store data in a form readable by a computer (solid state drives, flash memory cards, digital disks, random access memory (RAM), etc.) that are connected to the system bus 23 through the controller 55.

Computer 20 has a file system 36 where the recorded operating system 35 is stored, as well as additional software applications 37, other program modules 38, and program data 39. The user is able to enter commands and information into personal computer 20 via input devices (keyboard 40, keypad “ the mouse "42). Other input devices (not displayed) can be used: microphone, joystick, game console, scanner, etc. Such input devices are, as usual, connected to the computer system 20 via a serial port 46, which in turn is connected to the system bus, but can be connected in another way, for example, using a parallel port, a game port, or a universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface such as a video adapter 48. In addition to the monitor 47, the personal computer may be equipped with other peripheral output devices (not displayed), such as speakers, a printer, and the like.

The personal computer 20 is capable of operating in a networked environment, using a network connection with another or more remote computers 49. The remote computer (or computers) 49 are the same personal computers or servers that have most or all of the elements mentioned earlier in the description of the creature the personal computer 20 of FIG. 4. Other devices, such as routers, network stations, peer-to-peer devices, or other network nodes may also be present on the computer network.

Network connections can form a local area network (LAN) 50 and a wide area network (WAN). Such networks are used in corporate computer networks, internal networks of companies and, as a rule, have access to the Internet. In LAN or WAN networks, the personal computer 20 is connected to the local area network 50 via a network adapter or network interface 51. When using the networks, the personal computer 20 may use a modem 54 or other means of providing communication with a global computer network such as the Internet. The modem 54, which is an internal or external device, is connected to the system bus 23 via the serial port 46. It should be clarified that the network connections are only exemplary and are not required to display the exact network configuration, i.e. in reality, there are other ways to establish a technical connection between one computer and another.

In conclusion, it should be noted that the information provided in the description are examples that do not limit the scope of the present invention defined by the claims.

Claims (2)

1. The method of organizing the execution of more than one hypervisor in the same computer system, while one of the hypervisors must be constantly executed, the method itself contains the steps:
a) execute the code in hypervisor mode on the part of that hypervisor, which must be constantly executed, while other hypervisors do not require code execution in hypervisor mode;
b) monitor the state of the computer system, while the state of the computer system is associated with an attempt to start code execution in hypervisor mode from other hypervisors;
c) stop the execution of the code in the hypervisor mode from that hypervisor, which must be constantly executed, when the state of the computer system changes;
d) maintain the state of the computer system when the code is stopped in the hypervisor mode from that hypervisor, which must be constantly executed;
e) load the state of the computer system necessary to execute the code in hypervisor mode from the side of the hypervisor that attempted to run the code in hypervisor mode;
f) execute the code in hypervisor mode from the side of the hypervisor that attempted to run the code in hypervisor mode;
g) monitor the state of the computer system to wait for the possibility of running the code in hypervisor mode from that hypervisor, which must be constantly executed;
h) load the state of the computer system stored in step g);
i) run the code in hypervisor mode from that hypervisor, which should be constantly executed, when the opportunity arises in step g). 2. The method of claim 1, wherein the state of the computer system includes the state of the processor.

Images