Virtual Machine Container Device, Virtual Machine Container Control Method, Program, and Recording Medium

Abstract

To provide a virtual machine container apparatus which can execute a container for an OS different from a host OS in a container-based virtualization environment.SOLUTION: In a virtual machine container apparatus 10, a virtual machine monitor unit 12 acquires a system call generated by a process of an application loaded to a virtual machine container unit 11. A system call control unit 13 determines whether an OS of the application and an OS of a host OS kernel unit 14 are the same or not, using the system call acquired by the virtual machine monitor unit. When a determination is made that the OSs are the same, the host OS kernel unit 14 executes the system call, and returns an execution result to the process. When a determination is made that the OSs are different from each other, an OS kernel emulation unit 15 emulates the system call in accordance with the OS of the application, and returns an execution result of the emulation to the process.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a virtual machine container device, a virtual machine container control method, a program, and a recording medium. [Background technology]

[0002] Virtual machine virtualization is known as a technology for virtualizing the hardware (H / W) environment that implements an operating system (OS). In virtual machine virtualization, a virtual machine environment is configured using virtualization functions provided by the hardware. In addition, in virtual machine virtualization, a guest OS is started within each virtual machine. Therefore, with virtual machine virtualization, any OS can be run within each virtual machine, regardless of the host OS.

[0003] Container-based virtualization is also known as a technology for virtualizing the process execution environment provided by an OS (Patent Document 1). In container-based virtualization, a container, which is an application execution environment, is configured using the functions of the host OS. Each container has independent resources.

[0004] Furthermore, unikernel container virtualization is also known as a technology that has an execution environment similar to container virtualization. In unikernel container virtualization, a library that emulates OS functions (also called an emulation library) is combined with an application and placed in a container. The emulation library then emulates the system call functions of the guest OS. In addition, in unikernel container virtualization, system calls of the guest OS are converted into system calls of the host OS as necessary and executed. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Special Publication No. 2021-521530 Summary of the Invention [Problem to be solved by the invention]

[0006] However, the virtual machine-based virtualization requires a large number of resources to run a full-spec guest OS, resulting in a long startup time. In contrast, the container-based virtualization requires fewer resources and can start up quickly because each container does not have OS functions. However, the container-based virtualization has the problem that multiple containers share the same host OS, making it impossible to execute container processing for an OS different from the host OS. The unikernel container-based virtualization, through the emulation described above, can execute applications for an OS different from the host OS while maintaining the low resource and fast startup benefits of the container-based virtualization. However, the unikernel container-based virtualization requires the development of an emulation library for each guest OS. Furthermore, applications to be executed in the container must be modified and integrated with libraries, resulting in the inability to execute existing applications as is within the container. Similarly, there is also the problem that commercially available applications cannot be executed.

[0007] Therefore, an object of the present invention is to provide a virtual machine container device, a control method for a virtual machine container, a program, and a recording medium that can execute a container for an OS different from a host OS in a container-type virtualization environment. [Means for solving the problem]

[0008] In order to achieve the above object, the virtual machine container device of the present invention comprises: The virtual machine container unit includes a virtual machine monitor unit, a system call control unit, a host OS kernel unit, and an OS kernel emulation unit. the virtual machine container unit is capable of executing a loaded application; the virtual machine monitor unit is capable of acquiring a system call generated by a process of the application; the system call control unit determines whether the OS of the application and the OS of the host OS kernel unit are the same or different from each other based on the system call acquired by the virtual machine monitor unit; If it is determined that the processes are the same in the determination of whether they are different or the same, the host OS kernel executes the system call and returns the execution result to the process; If it is determined that the applications are different in the determination of whether they are the same or different, the OS kernel emulation unit emulates the system call in accordance with the OS of the application, and returns the result of the emulation to the process.

[0009] The method for controlling a virtual machine container of the present invention includes: The virtual machine container process includes a virtual machine monitor process, a system call control process, a host OS kernel process, and an OS kernel emulation process; The virtual machine container process executes an application loaded into the virtual machine container; The virtual machine monitor process acquires a system call generated by a process of the application, the system call control step determines whether the OS of the application and the OS handled by the host OS kernel step are different from each other based on the system call acquired by the virtual machine monitor step; If it is determined that the processes are the same in the determination of whether they are different or the same, the host OS kernel process executes the system call and returns the execution result to the process; If it is determined that the applications are different in the determination of whether they are the same or different, the OS kernel emulation step emulates the system call in accordance with the OS of the application, and returns the result of the emulation to the process. [Effects of the Invention]

[0010] According to the present invention, a container for an OS different from the host OS can be executed in a container-based virtualization environment. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 is a block diagram illustrating an example of the configuration of a virtual machine container apparatus according to the first embodiment. [Figure 2] FIG. 2 is a block diagram illustrating an example of a hardware configuration of the virtual machine container apparatus according to the first embodiment. [Figure 3] FIG. 3 is a flowchart illustrating an example of processing in the virtual machine container control method according to the first embodiment. [Figure 4A] FIG. 4A is a flowchart showing an example of execution of a virtual machine container in the control method of a virtual machine container according to the second embodiment. [Figure 4B] FIG. 4B is a flowchart showing an example of the execution of a system call in the control method for a virtual machine container according to the second embodiment. [Figure 5A] FIG. 5A is a schematic diagram showing an example of a virtualization environment and system call execution in virtual machine-based virtualization. [Figure 5B] FIG. 5B is a schematic diagram illustrating an example of a virtualization environment and system call execution in container-based virtualization. [Figure 5C] FIG. 5C is a schematic diagram illustrating an example of a virtualization environment and system call execution in Unikernel container-based virtualization. [Figure 5D] FIG. 5D is a schematic diagram illustrating an example of a virtualization environment and system call execution in the virtual machine container device of the second embodiment. [Figure 6] FIG. 6 is a flowchart showing an example of processing by the virtual machine monitor unit when the control transfer is not caused by the system call. DETAILED DESCRIPTION OF THE INVENTION

[0012] In the virtual machine container device of the present invention, for example, In the determination of whether the OS of the application is the same or different, the system call control unit determines the compatibility of the OS of the application with the OS of the host OS kernel unit, and if it determines that a part of the OS of the application is incompatible with the OS of the host OS kernel unit and the other parts are compatible, the host OS kernel executes the compatible portion of the system call and returns the execution result to the process; The OS kernel emulation unit may emulate the incompatible part of the system call in accordance with the OS of the application, and return the result of the emulation to the process.

[0013] The virtual machine container device of the present invention includes, for example: Further, a communication unit is included, the communication unit is capable of communicating with other devices via an external network; If, in determining whether or not the OS of the application is different from the OS of the host OS kernel unit and the OS kernel emulation unit determines that the OS is not capable of being emulated, the system call control unit may cause the other device capable of executing the OS of the application to execute the system call via the communication unit, and return the execution result to the process.

[0014] In the virtual machine container device of the present invention, for example, The virtual machine container unit may be generated by a hardware virtualization function.

[0015] In the virtual machine container method of the present invention, for example, In the determination of similarity or difference, the system call control process determines the compatibility of the OS of the application with the OS handled by the host OS kernel process, and when it determines that a part of the OS of the application is incompatible with the OS handled by the host OS kernel process and the other part is compatible, The host OS kernel process executes the compatible portion of the system call and returns the execution result to the process; The OS kernel emulation step may be configured to emulate the incompatible part of the system call in accordance with the OS of the application, and return the result of the emulation to the process.

[0016] The virtual machine container method of the present invention includes, for example, If, in the determination of whether or not the OS is the same as the OS handled by the host OS kernel process and the OS kernel emulation process determines that the OS of the application is different from the OS handled by the host OS kernel process and cannot be emulated, the system call control process may have another device capable of executing the OS of the application execute the system call via a communication unit and return the execution result to the process.

[0017] In the virtual machine container method of the present invention, for example, The virtual machine container handled by the virtual machine container process may be generated by a hardware virtualization function.

[0018] The program of the present invention is a program for causing a computer to execute the steps of the method of the present invention as a procedure.

[0019] The recording medium of the present invention is a computer-readable recording medium on which the program of the present invention is recorded.

[0020] In the present invention, "OS" is an abbreviation that means operating system.

[0021] Next, an embodiment of the present invention will be described using the drawings. The present invention is not limited to the following embodiment. In each of the following drawings, the same parts are assigned the same reference numerals. Furthermore, the descriptions of each embodiment can be used interchangeably unless otherwise specified, and the configurations of each embodiment can be combined unless otherwise specified. In this specification, the term "unit" can include, for example, a combination of hardware resources implemented by a circuit in a broad sense and software information processing that can be specifically realized by these hardware resources.

[0022] [Embodiment 1] 1 is a block diagram showing an example of the configuration of a virtual machine container device 10 according to this embodiment. As shown in FIG. 1, the device 10 includes a virtual machine container unit 11, a virtual machine monitor unit 12, a system call control unit 13, a host OS kernel unit 14, and an OS kernel emulation unit 15. The device 10 may further include a communication unit 16 or the like as an optional component.

[0023] The device 10 may be, for example, a single device including the above-mentioned units, or a device in which the above-mentioned units can be connected via a communication network. In this embodiment, the above-mentioned units may be connected to each other by, for example, an internal bus.

[0024] The device 10 can also be connected to an external device (described later) via the communication network. The communication network is not particularly limited and can be any known network, and may be wired or wireless. Examples of the communication network include the Internet, the World Wide Web (WWW), a telephone line, a Local Area Network (LAN), a Storage Area Network (SAN), a Delay Tolerant Networking (DTN), a Low Power Wide Area Network (LPWA), and a Local 5G (L5G). Examples of wireless communication include Wi-Fi (registered trademark), Bluetooth (registered trademark), Local 5G, and LPWA. Examples of wireless communication include direct communication between devices (Ad Hoc communication), infrastructure communication, and indirect communication via an access point.

[0025] The device 10 may be incorporated into a server as a system, for example.

[0026] The device 10 may be, for example, a personal computer (PC, e.g., desktop or notebook type) on which the program of the present invention is installed, a smartphone, a tablet terminal, a wearable terminal, etc. In this embodiment, the device 10 can realize the functions of each of the above-mentioned parts by software (e.g., the program of the present invention) loaded onto a main memory, for example.

[0027] All or part of the components of the device 10 may be realized on the cloud. The device 10 may be in the form of cloud computing or edge computing, for example, in which at least one of the components is on a server and the other components are on a terminal.

[0028] FIG. 2 illustrates a block diagram of the hardware configuration of the device 10. The device 10 may include, for example, a central processing unit (CPU, GPU, etc.) 101, a memory 102, a bus 103, a storage device 104, an input device 105, an output device 106, and a communication device 107. Note that these are merely examples, and the hardware configuration of the device 10 is not limited to these as long as it is capable of executing the processing of each of the above-mentioned units. Furthermore, the number of central processing units 101, etc. included in the device 10 is not limited to the example shown in FIG. 2; for example, the device 10 may include multiple central processing units 101. The units in the hardware configuration of the device 10 are connected to each other via their respective interfaces (I / F) and a bus 103.

[0029] The central processing unit 101 is responsible for overall control of the device 10. In the device 10, the central processing unit 101 executes, for example, the program of the present invention and other programs, and also reads and writes various types of information. The central processing unit 101 executes, for example, the functions of each part of the device 10.

[0030] The bus 103 can also be connected to, for example, an external device. Examples of the external device include an external storage device (such as an external database), an external input device, and an external output device. The device 10 can be connected to an external network (the communication line network) by, for example, a communication device 107 connected to the bus 103, and can also be connected to other devices via the external network. The communication device 107 functions as, for example, a communication unit 16.

[0031] The memory 102 may be, for example, a main memory (primary storage device). When the central processing unit 101 performs processing, the memory 102 reads various operating programs, such as the program of the present invention, stored in the storage device 104 (described later), and the central processing unit 101 receives data from the memory 102 and executes the programs. The main memory may be, for example, a RAM (random access memory). Alternatively, the memory 102 may be, for example, a ROM (read only memory).

[0032] The storage device 104 is also referred to as an auxiliary storage device, for example, in contrast to the main memory (primary storage device). As described above, the storage device 104 stores an operating program including the program of the present invention. The storage device 104 may be, for example, a combination of a recording medium and a drive that reads and writes data from and to the recording medium. The recording medium is not particularly limited and may be, for example, an internal or external type, such as a hard disk (HD), CD-ROM, CD-R, CD-RW, MO, DVD, flash memory, or memory card. The storage device 104 may be, for example, a hard disk drive (HDD) or a solid state drive (SSD) in which the recording medium and drive are integrated.

[0033] In the present device 10, the memory 102 and the storage device 104 can also store various information such as log information, information acquired from an external database (not shown) or an external device, information generated by each process of the present device 10, and information used when the present device 10 executes each process. Note that at least a portion of the information may be stored, for example, in an external server other than the memory 102 and the storage device 104, or may be stored in a distributed manner across multiple terminals using blockchain technology or the like.

[0034] The device 10 may further include, for example, an input device 105 and an output device 106. The input device 105 is a device for inputting, for example, letters, numbers, the position of an object displayed on the screen, an image, sound, etc., and specific examples thereof include a digitizer (such as a touch panel), a keyboard, a mouse, a scanner, an imaging device, a microphone, a sensor, etc. The output device 106 is, for example, a display device (such as an LED display or a liquid crystal display), a printer, a speaker, etc.

[0035] Next, an example of a control method for a virtual machine container according to this embodiment (hereinafter also simply referred to as a control method) will be described with reference to the flowchart of Fig. 3. The control method according to this embodiment is implemented as follows, for example, using the virtual machine container apparatus 10 of Fig. 1. Note that the control method according to this embodiment is not limited to use of the virtual machine container apparatus 10 of Fig. 1.

[0036] In the following, the virtual machine container process can be executed, for example, by a virtual machine container unit 11, the virtual machine monitor process can be executed, for example, by a virtual machine monitor unit 12, the system call control process can be executed, for example, by a system call control unit 13, the host OS kernel process can be executed, for example, by a host OS kernel unit 14, and the OS kernel emulation process can be executed, for example, by an OS kernel emulation unit 15.

[0037] First, the virtual machine container unit 11 executes the loaded application (S11). Next, the virtual machine monitor unit 12 acquires a system call generated by the process of the application (S12). Next, the system call control unit 13 determines whether the OS of the application and the OS of the host OS kernel unit 14 (i.e., the host OS) are the same or different based on the system call acquired by the virtual machine monitor unit 12 (S13). If it is determined that they are the same (A), the host OS kernel unit 14 executes the system call and returns the execution result to the process (S14), and the process ends (END). The "execution of the system call" by the host OS kernel unit 14 can also be referred to as, for example, "responding to the system call." On the other hand, if it is determined that they are different (B), the OS kernel emulation unit 15 emulates the system call according to the OS of the application, returns the execution result of the emulation to the process (S15), and the process ends (END).

[0038] The virtual machine container unit 11 may be generated by, for example, a hardware virtualization function. The hardware virtualization function is, for example, a function provided by hardware that realizes a virtual machine function having a virtual machine container. Here, a virtual machine container refers to an application execution environment on a virtual machine that is isolated from other environments by separating a part of a running OS. When the virtual machine container unit 11 is generated by the hardware virtualization function, the virtual machine monitor unit 12, for example, uses the hardware virtualization function to acquire system calls generated by the application process. In this way, by using the virtual machine function provided by the hardware virtualization function, the system calls can be trapped without requiring software modifications. Furthermore, by using the virtual machine function provided by the hardware virtualization function, the system calls can be trapped without increasing the overhead during software execution.

[0039] In the present invention, the virtual machine container may include, for example, an OS (guest OS), but it does not have to include an OS (guest OS).

[0040] Now, applications and system calls will be explained. Applications run by calling functions of the kernel, which is the core of the OS. Such calls to the kernel are called system calls.

[0041] The virtual machine monitor unit 12 can also be called a hypervisor. Specific processing by the virtual machine monitor unit 12 will be described in a second embodiment below.

[0042] In the system call control unit 13, "the difference between the OS of the application and the OS of the host OS kernel unit 14" specifically refers to the difference between the types of OS. Then, the host OS kernel unit 14 and the OS kernel emulation unit 15 operate as described above depending on the type of OS. The system call control unit 13 is also called a dispatcher, for example, and may be part of the virtual machine monitor unit 12.

[0043] For example, in addition to determining whether the OS of the application is the same or different (S13), the system call control unit 13 may determine the compatibility of the OS of the application with the OS of the host OS kernel unit 14. If it is determined (C) that a portion of the OS of the application is incompatible with the OS of the host OS kernel unit 14 and the other portions are compatible, the host OS kernel unit 14 may execute the compatible portion of the system call and return the execution result to the process (S16). Meanwhile, the OS kernel emulation unit 15 may emulate the incompatible portion of the system call in accordance with the OS of the application and return the execution result of the emulation to the process (S16). After executing step S16, the process ends (END). As described above, by emulating only the incompatible system calls and executing the compatible system calls in the host OS, the development of an emulator can be simplified.

[0044] Emulation by the OS kernel emulator unit 15 will now be described. In the case where an OS on which an application runs (hereinafter also referred to as the target OS) and a host OS provide the same functions but have different interfaces for the functions, the emulation converts the interface of the functions provided by the target OS to match the interface of the functions provided by the host OS, and then issues a system call to the host OS. Specifically, for example, the emulation executes one of the methods described below in (1) to (4) depending on the degree of difference between the interfaces.

[0045] (1) When the order of parameters when invoking a system call is different The parameters of the system call issued by the application are converted into the order expected by the host OS.

[0046] (2) When the parameter values ​​and their meanings at the time of invoking a system call are different The parameter values ​​of the system call issued by the application are converted into values ​​expected by the host OS based on a conversion table or conversion rules.

[0047] (3) When the same function as the function provided by the target OS can be realized by combining the functions provided by the host OS. In order to realize the requested system call function in the host OS, the system call is converted into a series of system call invocations of the host OS. If necessary, the parameters at the time of the system call invocation are also converted into the order and values ​​expected by the host OS.

[0048] (4) When the system calls of the host OS alone cannot provide the same functionality as the functions provided by the target OS. A program for providing the same function is implemented within the emulator or as an external component and used.

[0049] As described above, the device 10 may further include, for example, a communication unit 16. The communication unit 16 is capable of communicating with other devices via an external network. In an embodiment including the communication unit 16, the system call control unit 13 may, in addition to determining whether the OS of the application is the same or different (S13), determine whether emulation by the OS kernel emulation unit 15 is possible. If the system call control unit 13 determines that the OS of the application is different from the OS of the host OS kernel unit 14 and that emulation by the OS kernel emulation unit 15 is impossible (D), the system call control unit 13 may, for example, cause the other device capable of executing the OS of the application to execute the system call via the communication unit 16, return the execution result to the process (S17), and terminate (END). The other device is not particularly limited and may be a virtual machine or a physical machine. "Emulation by the OS kernel emulation unit 15 is impossible" includes cases where emulation is completely impossible, as well as cases where emulation would degrade the performance of the device 10 or where developing an emulation function would require cost and effort. According to this aspect, even in the above-mentioned case, the system call can be executed. On the other hand, for example, if it is determined that the OS of the application is different from the OS of the host OS kernel unit 14 and can be emulated by the OS kernel emulation unit 15, the same process as step S15 may be executed.

[0050] The system call control unit 13 may, for example, determine whether the incompatible part between the OS of the application and the OS of the host OS kernel unit 14 can be emulated by the OS kernel emulation unit 15. If it is determined that the incompatible part cannot be emulated, the system call control unit 13 may, for example, cause the other device to emulate the incompatible part of the system call and cause the other device to execute the incompatible part of the system call.

[0051] The invention of this embodiment has the following effects, for example.

[0052] (1) Resources and overhead, etc. According to this embodiment, each virtual machine container unit 11 does not need to have an OS, so applications for multiple OSs can be executed on a single host OS with fewer resources and lower overhead than in a conventional virtual machine-based virtualization environment. Lower overhead means faster startup speed. Furthermore, according to this embodiment, the emulation allows the applications to be executed even if the multiple OSs are different from the host OS.

[0053] (2) Degree of design freedom, etc. This embodiment increases the degree of freedom in designing applications that are configured with multiple virtual machine containers. For example, it is possible to configure a web server as a container with a Linux (registered trademark) OS and a database as a container with a Windows (registered trademark) OS. In addition, existing applications and commercially available applications can be run as is in the container without modifying the application to be run in the container or integrating it with libraries.

[0054] (3) Construction costs and operating costs, etc. When the processing of each part of the device 10 (virtual machine container part 11, virtual machine monitor part 12, system call control part 13, host OS kernel part 14, and OS kernel emulation part 15) is realized by software loaded on main memory, the construction costs and operation costs of the hardware (or virtual machine) and host OS required to execute the container can be reduced. Specifically, the costs of preparing a hardware environment on which the OS runs for each type of OS, constructing an OS environment on that, and managing and operating these can be reduced. Furthermore, by standardizing the host OS, it is possible to construct a cluster and improve redundancy at low cost. Furthermore, there is no need to develop an emulation library.

[0055] (4) Communication speed According to this embodiment, communication between containers for different OSs can be accelerated. This point will be explained in more detail. In a conventional virtual machine-based virtualization environment, communication between OSs results in large overhead. However, communication between containers on the same host can be achieved by memory-to-memory copying, so according to this embodiment, communication between containers for different OSs is faster than with conventional virtual machine-based virtualization.

[0056] [Embodiment 2] The virtual machine container apparatus 10 and the control method of the first embodiment will be described in more detail.

[0057] An example of the control method of this embodiment shown in FIG. 3 will be described in more detail with reference to FIGS. 4A and 4B. FIG. 4A is a flowchart showing an example of execution of a virtual machine container in the control method of this embodiment. First, as a preparation stage, steps S21 to S23 shown in FIG. 4A are executed. Step S21 is a step of generating the virtual machine container unit 11. As described above, the virtual machine container unit 11 can be generated by a hardware virtualization function. Step S22 is a step of setting the virtual machine container unit 11 to trap a system call. The system call is generated by a process of an application loaded in step S23, which will be described later. Step S23 is a step of loading an application into the memory space of the virtual machine container unit 11. Then, the application is executed in the virtual machine container unit 11 (S24).

[0058] Next, as the execution stage of the virtual machine container unit 11, steps S25 to S28 shown in FIG. 4A are executed. These steps are executed, for example, by hardware (e.g., the central processing unit 101) corresponding to the virtual machine container unit 11. Step S25 is a step of acquiring an instruction from the application. Step S26 is a step of determining whether the instruction is a specific instruction (including an instruction related to a system call). The specific instruction is, for example, an instruction that may cause a problem in the system if the application is allowed to run as is in the virtual machine container unit 11. More specifically, examples of the specific instruction include an instruction that requires special privileges and an instruction that accesses an unauthorized memory area. The fact that the application is attempting to execute the specific instruction is detected, for example, by a hardware virtualization function. Step S27 is a step of executing the instruction in the virtual machine container unit 11 if the instruction is not the specific instruction (NO). Step S28 is a step of temporarily suspending execution of the specific instruction in the virtual machine container unit 11 and transferring processing related to the specific instruction to the virtual machine monitor unit 12 if the instruction is the specific instruction (YES). If the specific command is a command related to a system call, the virtual machine monitor unit 12 executes processing such as acquiring the system call, and the system call is executed (S29), as described in FIG. 3. Processing when the specific command is not a command related to a system call will be described later with reference to FIG. 6. The execution of the virtual machine container in the control method of this embodiment ends after, for example, either step S27 or step S29 is executed (END). In the control method of this embodiment, for example, after step S27 and step S29, the processing may be repeated from step S25.

[0059] 4B is a flowchart showing an example of system call execution in the control method of this embodiment. First, as a preliminary step, in step S31, as explained in FIG. 4A, control related to the processing of the specific command is transferred to the virtual machine monitor unit 12. Next, in step S32, it is determined whether the transfer (hereinafter also referred to as control transfer) is caused by the system call, i.e., whether the specific command is a command related to a system call. Step S32 is executed, for example, by the virtual machine monitor unit 12. If the control transfer is not caused by the system call (NO), the process proceeds to step S33.

[0060] 6 is a flowchart showing an example of the process of the virtual machine monitor unit 12 when the control transfer is not caused by the system call. The step S33 includes, for example, steps S33-1 to S33-3 shown in FIG. 6. First, the specific command that the application is attempting to execute is confirmed, and a determination is made as to whether or not to permit execution of the specific command (step S33-1). If the result of the determination is that the execution of the specific command is not permitted (NO), the virtual machine monitor unit 12 returns an error to the application or terminates the application depending on the situation (step S33-2), and then terminates (END). On the other hand, if the result of the determination is that the execution of the specific command is permitted (YES), the virtual machine monitor unit 12 returns control to the application in the virtual machine container unit 11, for example, and resumes execution of the specific command in the virtual machine container unit 11 (step S33-3), and then terminates (END). More specifically, "permitting execution of the command" means, for example, granting special authority when executing the command, permitting access to a memory area, or the like. Furthermore, depending on the specific command that the application is trying to execute, the virtual machine monitor unit 12 may execute the specific command in a safe manner on behalf of the application and return the result to the application.

[0061] In step S32 of FIG. 4B, if the control transfer is due to the system call (YES), the process proceeds to step S34. Step S34 is a step of acquiring the OS type of the virtual machine container unit 11. Step S34 is executed by, for example, the system call control unit 13. Next, in step S35, the system call control unit 13 determines whether the OS of the application is the same as the host OS. If it is determined that they are the same OS (YES), in step S36, control related to the command is transferred to the OS (host OS) of the host OS kernel unit 14, and the host OS kernel unit 14 executes the system call. On the other hand, if it is determined that they are different OSs (NO), in step S37, it is determined whether the OS of the application is an OS that can be emulated. The determination in step S37 is executed by, for example, the system call control unit 13. If it is determined that the OS is an OS that can be emulated (YES), in step S38, control related to the command is transferred to the emulation of the OS kernel emulation unit 15, and the system call is executed by the emulation. On the other hand, if it is determined that the OS is not emulatable (NO), in step S39, it is determined whether the OS of the application is an OS that can be remotely executed (communication with the communication unit 16). Step S39 is executed, for example, by the system call control unit 13. If it is determined that the OS is remotely executable (YES), in step S40, control related to the command is transferred to the OS of the other device, and the system call is executed by the other device. On the other hand, if it is determined that the OS is not remotely executable (NO), in step S41, the system call control unit 13 returns an error to the process. The error means that the system call cannot be executed. After execution of step S41, for example, the processing related to the execution of the system call is terminated (END). After execution of any one of step S36, step S38, or step S40, the execution result of the system call is returned to the process (S42). Then, the processing is terminated (END).

[0062] The virtual machine type virtualization, container type virtualization, unikernel container type virtualization, and the virtual machine container device 10 of this embodiment will be described in more detail. FIG. 5A is a schematic diagram showing an example of a virtualization environment and system call execution in virtual machine type virtualization. FIG. 5B is a schematic diagram showing an example of a virtualization environment and system call execution in container type virtualization. FIG. 5C is a schematic diagram showing an example of a virtualization environment and system call execution in unikernel container type virtualization. FIG. 5D is a schematic diagram showing an example of a virtualization environment and system call execution in the virtual machine container device 10 of this embodiment. In FIGS. 5A to 5D, "app" stands for application, and "SVC" stands for system call (supervisor call). In the following description and FIGS. 5A to 5D, OS-A, OS-B, and OS-C refer to types of OS.

[0063] First, virtual machine-based virtualization will be described using FIG. 5A. In this example, as shown in FIG. 5A(A), a virtual machine 1 is constructed on a host OS (host OS kernel 14A), which is OS-A, and has an application 2c for OS-C and a guest OS kernel 3. The guest OS is OS-C. In virtual machine-based virtualization, the guest OS kernel 3 receives a system call from the application 2c. The guest OS kernel 3 executes hardware access, etc. When the hardware access, etc. is executed, a hardware virtualization function traps it, and control is transferred to the virtual machine monitor 12A. Then, in virtual machine-based virtualization, the virtual machine monitor 12A executes the system call. As described above, in virtual machine-based virtualization, since it is necessary to go through the guest OS kernel 3, many resources are required to run the guest OS, and startup takes time, as described above.

[0064] Next, container-based virtualization will be described with reference to FIG. 5B. In this example, a container 4 is constructed on a host OS (host OS kernel 14B) that is OS-A, and has an application 2a for OS-A. The container 4 is generated and operated by a container runtime 5. In container-based virtualization, the host OS kernel 14B directly receives a system call generated by the process of application 2a from application 2a and executes the system call. In this way, in container-based virtualization, multiple containers 4 share the same host OS (host OS kernel 14B), and therefore, as described above, it is not possible to execute processing of a container having an application for an OS different from the host OS.

[0065] Next, Unikernel container-type virtualization will be described using FIG. 5C. In this example, the Unikernel container 6 is constructed on a host OS (host OS kernel 14C) which is OS-A, and has an application 2c for OS-C and a kernel emulation library 7 for OS-C. In Unikernel container-type virtualization, the application 2c calls the kernel emulation library 7. Then, the host OS kernel 14C obtains a system call from the kernel emulation library 7 and executes the system call. The kernel emulation library 7 is an implementation of the system call function provided by the OS kernel of the host OS (host OS kernel 14C) in the form of a library program that can be combined with an application. As described above, in Unikernel container-type virtualization, a kernel emulation library 7 needs to be developed for each OS of the application 2c.

[0066] Finally, the virtual machine container device 10 of this embodiment will be described with reference to Fig. 5D. In Fig. 5D, the virtual machine containers 11A to 11C correspond to the virtual machine container unit 11, the virtual machine monitor 12D corresponds to the virtual machine monitor unit 12, and the dispatcher 13D corresponds to the system call control unit 13. The host OS kernel 14D corresponds to the host OS kernel unit 14, and the OS kernel emulator 15D and the virtual machine 8 correspond to the OS kernel emulation unit 15. In this example, the type of the host OS in the host OS kernel 14D is OS-A. However, the present invention is not limited to this example.

[0067] First, we will explain the virtual machine container 11A, which has application 2a for OS-A, as an example. The virtual machine monitor 12D acquires a system call generated by the process of application 2a in the virtual machine container 11A. More specifically, for example, when the process of application 2a issues a system call, the hardware virtualization function traps it, and control is transferred to the virtual machine monitor 12D. Then, the dispatcher 13D determines that the OS of application 2a is the same as the host OS, and passes the system call to the host OS kernel 14D. The host OS kernel 14D then executes the system call.

[0068] Next, an example will be described in which a virtual machine container 11B having an application 2b for OS-B is used. The virtual machine monitor 12D acquires a system call generated by the process of application 2b in the virtual machine container 11B. More specifically, for example, when the process of application 2b issues a system call, the hardware virtualization function traps it, and control is transferred to the virtual machine monitor 12D. In this example, the OS of application 2b is OS-B, and the OS of the host OS kernel 14D is OS-A. Therefore, the dispatcher 13D determines that the OS of application 2b is different from the host OS. After this determination, the OS kernel emulator 15D emulates the system call for OS-B into a system call for OS-A. Then, the host OS kernel 14D executes the system call for OS-A. Furthermore, if the dispatcher 13D determines that part of the OS of application 2b is incompatible with the host OS, but the other parts are compatible, the host OS kernel 14D may execute the compatible part of the system call. On the other hand, the OS kernel emulator 15D may emulate the incompatible part of the system call for OS-B into a system call for OS-A. Then, the host OS kernel 14D executes the system call of the incompatible part emulated into the system call for OS-A. Note that the kernel emulation library 7 in FIG. 5C differs from the OS kernel emulator 15D in that it implements only the OS functions required by the application, is executed in conjunction with the application, and is called directly by the application.

[0069] Finally, a virtual machine container 11C having an application 2c for OS-C will be described as an example. The virtual machine monitor 12D acquires a system call generated by the process of application 2c in the virtual machine container 11C. More specifically, for example, when the process of application 2c issues a system call, the hardware virtualization function traps it, and control is transferred to the virtual machine monitor 12D. In this example, the OS of application 2c is OS-C, and the OS of the host OS kernel 14D is OS-A. Therefore, the dispatcher 13D determines that the OS of application 2c is different from the host OS. In addition to this determination by the dispatcher 13D, if the dispatcher 13D determines that emulation by the OS kernel emulator 15D is not possible, the dispatcher 13D causes another device 20 to emulate and execute the system call, for example, via the communication unit 16. The other device 20 has OS-C as its host OS (kernel). On the other hand, the dispatcher 13D may, for example, cause a virtual machine 8 having an OS-C as a guest OS 9 to emulate the system call and execute the system call. That is, the virtual machine 8 can also function as the OS kernel emulation unit 15.

[0070] [Embodiment 3] The program of this embodiment is a program for causing a computer to execute each step of the method of the present invention as a procedure. In the present invention, "procedure" may be read as "processing." The program of this embodiment may be recorded, for example, on a computer-readable recording medium. The recording medium is, for example, a non-transitory computer-readable storage medium. The recording medium is not particularly limited, and examples thereof include a read-only memory (ROM), a hard disk (HD), an optical disk, etc.

[0071] Although the present invention has been described above with reference to the embodiments, the present invention is not limited to the above embodiments. Various modifications that can be understood by those skilled in the art can be made to the configuration and details of the present invention within the scope of the present invention.

[0072] <Additional Notes> Some or all of the above embodiments can be described as, but not limited to, the following supplementary notes. (Appendix 1) The virtual machine container unit includes a virtual machine monitor unit, a system call control unit, a host OS kernel unit, and an OS kernel emulation unit. the virtual machine container unit is capable of executing a loaded application; the virtual machine monitor unit is capable of acquiring a system call generated by a process of the application; the system call control unit determines whether the OS of the application and the OS of the host OS kernel unit are the same or different from each other based on the system call acquired by the virtual machine monitor unit; If it is determined that the processes are the same in the determination of whether they are different or the same, the host OS kernel executes the system call and returns the execution result to the process; If it is determined that the system calls are different in the determination of whether they are the same or different, the OS kernel emulation unit emulates the system call in accordance with the OS of the application and returns the execution result of the emulation to the process. Virtual machine container device. (Appendix 2) In the determination of whether the OS of the application is the same or different, the system call control unit determines the compatibility of the OS of the application with the OS of the host OS kernel unit, and if it determines that a part of the OS of the application is incompatible with the OS of the host OS kernel unit and the other parts are compatible, the host OS kernel executes the compatible portion of the system call and returns the execution result to the process; the OS kernel emulation unit emulates the incompatible part of the system call in accordance with the OS of the application, and returns the result of the emulation to the process; 2. The virtual machine container apparatus of claim 1. (Appendix 3) Further, a communication unit is included, the communication unit is capable of communicating with other devices via an external network; when the system call control unit determines in the determination whether the OS of the application is different from the OS of the host OS kernel unit and cannot be emulated by the OS kernel emulation unit, the system call control unit causes the other device capable of executing the OS of the application to execute the system call via the communication unit, and returns the execution result to the process; 3. The virtual machine container device according to claim 1 or 2. (Appendix 4) The virtual machine container unit is generated by a hardware virtualization function. 4. A virtual machine container apparatus according to any one of appendices 1 to 3. (Appendix 5) The virtual machine container process includes a virtual machine monitor process, a system call control process, a host OS kernel process, and an OS kernel emulation process; The virtual machine container process executes an application loaded into the virtual machine container; The virtual machine monitor process acquires a system call generated by a process of the application, the system call control step determines whether the OS of the application and the OS handled by the host OS kernel step are different from each other based on the system call acquired by the virtual machine monitor step; If it is determined that the processes are the same in the determination of whether they are different or the same, the host OS kernel process executes the system call and returns the execution result to the process; If it is determined that the system calls are different in the determination of whether they are the same or different, the OS kernel emulation step emulates the system call in accordance with the OS of the application and returns the execution result of the emulation to the process. How to control virtual machine containers. (Appendix 6) In the determination of similarity or difference, the system call control process determines the compatibility of the OS of the application with the OS handled by the host OS kernel process, and when it determines that a part of the OS of the application is incompatible with the OS handled by the host OS kernel process and the other part is compatible, The host OS kernel process executes the compatible portion of the system call and returns the execution result to the process; the OS kernel emulation step emulates the incompatible part of the system call in accordance with the OS of the application, and returns the emulation execution result to the process; 6. The method for controlling a virtual machine container according to claim 5. (Appendix 7) When the system call control step determines in the determination whether the OS of the application is different from the OS handled by the host OS kernel step and cannot be emulated in the OS kernel emulation step, the system call control step causes another device capable of executing the OS of the application to execute the system call via a communication unit, and returns the execution result to the process. 7. A method for controlling a virtual machine container according to claim 5 or 6. (Appendix 8) The virtual machine container handled by the virtual machine container process is generated by a hardware virtualization function. 8. A method for controlling a virtual machine container according to any one of appendixes 5 to 7. (Appendix 9) A program for causing a computer to execute procedures including a virtual machine container procedure, a virtual machine monitor procedure, a system call control procedure, a host OS kernel procedure, and an OS kernel emulation procedure; The virtual machine container procedure executes an application loaded into the virtual machine container; The virtual machine monitor procedure obtains a system call generated by a process of the application; the system call control procedure determines whether an OS of the application and an OS handled by the host OS kernel procedure are different from each other based on the system call acquired by the virtual machine monitor procedure; If it is determined that the processes are the same in the determination of whether they are different or the same, the host OS kernel procedure executes the system call and returns the execution result to the process; If it is determined that the applications are different in the determination of whether they are the same or different, the OS kernel emulation procedure emulates the system call in accordance with the OS of the application, and returns the result of the emulation to the process. (Appendix 10) In the determination of similarity or difference, the system call control procedure determines the compatibility of the OS of the application with the OS handled by the host OS kernel procedure, and if it determines that a part of the OS of the application is incompatible with the OS handled by the host OS kernel procedure and that the other part is compatible, The host OS kernel procedure executes the compatible portion of the system call and returns the execution result to the process; the OS kernel emulation procedure emulates the incompatible part of the system call in accordance with the OS of the application, and returns the execution result of the emulation to the process; The program described in Appendix 9. (Appendix 11) If the system call control procedure determines in the determination of whether the OS of the application is different from the OS handled by the host OS kernel procedure and cannot be emulated by the OS kernel emulation procedure, the system call control procedure causes another device capable of executing the OS of the application to execute the system call via a communication unit, and returns the execution result to the process. 11. The program according to claim 9 or 10. (Appendix 12) The virtual machine container handled by the virtual machine container procedure is generated by a hardware virtualization function. 12. The program of any one of appendices 9 to 11. (Appendix 13) A computer-readable recording medium having recorded thereon a program according to any one of appendices 9 to 12. [Industrial Applicability]

[0073] According to the present invention, it is possible to execute a container for an OS different from the host OS, and therefore the present invention is particularly useful when executing an application in a container-type virtualization environment, for example. [Explanation of symbols]

[0074] 1, 8 virtual machines 2a, 2b, and 2c Applications 3 Guest OS kernel 4. Container 5. Container Runtime 6 Unikernel Containers 7 Kernel Emulation Library 9 Guest OS 10 Virtual Machine Container Device 11 Virtual Machine Container Section 11A, 11B, 11C Virtual Machine Containers 12 Virtual Machine Monitor 12A, 12D Virtual Machine Monitor 13 System call control section 13D Dispatcher 14 OS host kernel part 14A, 14B, 14C, 14D Host OS Kernel 15 OS kernel emulation section 15D OS kernel emulator 16 Communications Department 20 Other devices 101 Central Processing Unit 102 memory 103 Bus 104 Storage device 105 Input Device 106 Output Device 107 Communication Devices

Claims

1. The virtual machine container unit includes a virtual machine monitor unit, a system call control unit, a host OS kernel unit, and an OS kernel emulation unit. the virtual machine container unit is capable of executing a loaded application; the virtual machine monitor unit is capable of acquiring a system call generated by a process of the application; the system call control unit determines whether an OS of the application and an OS of the host OS kernel unit are the same or different from each other based on the system call acquired by the virtual machine monitor unit; If it is determined that the processes are the same in the determination of whether they are different or the same, the host OS kernel executes the system call and returns the execution result to the process; If it is determined that the applications are different in the determination of whether they are the same or different, the OS kernel emulation unit emulates the system call in accordance with the OS of the application and returns the result of the emulation to the process. Virtual machine container device.

2. When the system call control unit determines compatibility between the OS of the application and the OS of the host OS kernel unit in the determination of whether they are different or the same, and determines that a part of the OS of the application is incompatible with the OS of the host OS kernel unit and the other parts are compatible, the host OS kernel executes the compatible part of the system call and returns the execution result to the process; the OS kernel emulation unit emulates the incompatible part of the system call in accordance with the OS of the application, and returns the result of the emulation to the process; The virtual machine container device according to claim 1 .

3. Further, a communication unit is included, the communication unit is capable of communicating with other devices via an external network; When the system call control unit determines in the determination whether the OS of the application is different from the OS of the host OS kernel unit and cannot be emulated by the OS kernel emulation unit, the system call control unit causes the other device capable of executing the OS of the application to execute the system call via the communication unit, and returns the execution result to the process.

3. The virtual machine container device according to claim 1.

4. The virtual machine container unit is generated by a hardware virtualization function. The virtual machine container device according to claim 1 .

5. The process includes a virtual machine container process, a virtual machine monitor process, a system call control process, a host OS kernel process, and an OS kernel emulation process; The virtual machine container process executes an application loaded into the virtual machine container; The virtual machine monitor process acquires a system call generated by a process of the application, the system call control step determines whether an OS of the application and an OS handled by the host OS kernel step are different from each other based on the system call acquired by the virtual machine monitor step; If it is determined that the processes are the same in the determination of whether they are different or the same, the host OS kernel process executes the system call and returns the execution result to the process; If it is determined that the applications are different in the determination of whether they are the same or different, the OS kernel emulation step emulates the system call in accordance with the OS of the application and returns the execution result of the emulation to the process. How to control virtual machine containers.

6. In the determination of similarity or difference, the system call control process determines compatibility between the OS of the application and the OS handled by the host OS kernel process, and when it is determined that a part of the OS of the application is incompatible with the OS handled by the host OS kernel process and the other part is compatible, The host OS kernel process executes the compatible portion of the system call and returns the execution result to the process; the OS kernel emulation step emulates the incompatible part of the system call in accordance with the OS of the application, and returns the emulation execution result to the process; The method for controlling a virtual machine container according to claim 5.

7. When the system call control step determines in the determination whether the OS of the application is different from the OS handled by the host OS kernel step and that emulation by the OS kernel emulation step is not possible, the system call control step causes another device capable of executing the OS of the application to execute the system call via a communication unit, and returns the execution result to the process.

7. The method for controlling a virtual machine container according to claim 5 or 6.

8. The virtual machine container handled by the virtual machine container process is generated by a hardware virtualization function. The method for controlling a virtual machine container according to any one of claims 5 to 7.

9. a program for causing a computer to execute procedures including a virtual machine container procedure, a virtual machine monitor procedure, a system call control procedure, a host OS kernel procedure, and an OS kernel emulation procedure; The virtual machine container procedure executes an application loaded into the virtual machine container; The virtual machine monitor procedure obtains a system call generated by a process of the application; the system call control procedure determines whether an OS of the application and an OS handled by the host OS kernel procedure are the same or different from each other based on the system call acquired by the virtual machine monitor procedure; If it is determined that the processes are the same in the determination of whether they are different or the same, the host OS kernel procedure executes the system call and returns the execution result to the process; If it is determined that the two applications are different, the OS kernel emulation procedure emulates the system call in accordance with the OS of the application, and returns the result of the emulation to the process.

10. In the determination of similarity or difference, the system call control procedure determines the compatibility of the OS of the application with the OS handled by the host OS kernel procedure, and if it determines that a part of the OS of the application is incompatible with the OS handled by the host OS kernel procedure and the other part is compatible, The host OS kernel procedure executes the compatible portion of the system call and returns the execution result to the process; the OS kernel emulation procedure emulates the incompatible part of the system call in accordance with the OS of the application, and returns the emulation execution result to the process; The program according to claim 9.

Images