JP7729672B2 - Virtual Machine Container Device, Virtual Machine Container Control Method, Program, and Recording Medium - Google Patents

Description

The present invention relates to a virtual machine container device, a virtual machine container control method, a program, and a recording medium.

Virtual machine virtualization is known as a technology for virtualizing the H/W (hardware) environment that realizes an OS (operating system). With virtual machine virtualization, a virtual machine environment is constructed using the virtualization functions provided by the H/W (hardware). Furthermore, with 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.

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, the functions of the host OS are used to create containers, which are the execution environments for applications. Each container has independent resources.

Unikernel container virtualization is also known as a technology that has a similar execution environment to container virtualization. In this type of container virtualization, a library that emulates OS functions (also known as an emulation library) is combined with an application and placed inside a container. The emulation library then emulates the system call functions of the guest OS. In this type of container virtualization, the guest OS's system calls are converted into host OS system calls as necessary and then executed.

Special Publication No. 2021-521530

However, with virtual machine-based virtualization, running a full-spec guest OS requires a lot of resources, resulting in slow startup times. In contrast, with container-based virtualization, each container does not have OS functionality, so it operates with fewer resources and can start up quickly. However, with container-based virtualization, multiple containers share the same host OS, meaning that container processing for an OS different from the host OS cannot be executed. 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 requirements and fast startup benefits of container-based virtualization. However, with uniform container-based virtualization, emulation libraries must be developed for each guest OS. Furthermore, applications to be executed in the container must be modified and integrated with libraries, meaning that existing applications cannot be executed as is within the container. Similarly, commercially available applications cannot be executed.

The present invention therefore aims to provide a virtual machine container device, a virtual machine container control method, a program, and a recording medium that can run a container for an OS different from the host OS in a container-based virtualization environment.

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 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.

The method for controlling a virtual machine container of the present invention includes:
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 two 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.

According to the present invention, it is possible to run a container for an OS different from the host OS in a container-based virtualization environment.

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

In the virtual machine container device of the present invention, for example,
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 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.

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 the system call control unit determines, in the determination of 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, it may cause the other device that can execute the OS of the application to execute the system call via the communication unit, and return the execution result to the process.

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.

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 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 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.

The virtual machine container method of the present invention includes, for example,
If the system call control process determines in the determination of whether the OS of the application is different from the OS handled by the host OS kernel process and cannot be emulated in the OS kernel emulation process, 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.

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.

The program of the present invention is a program that causes a computer to execute each step of the method of the present invention as a procedure.

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

In this invention, "OS" is an abbreviation for operating system.

Next, embodiments of the present invention will be described using the drawings. The present invention is not limited to the following embodiments. In the following drawings, identical parts are designated by the same reference numerals. Furthermore, unless otherwise specified, the descriptions of each embodiment can be used interchangeably, 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 the broad sense and software information processing that can be specifically realized by these hardware resources.

[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.

The device 10 may be, for example, a single device including each of the above-mentioned components, or a device in which each of the above-mentioned components can be connected via a communications network. In this embodiment, the components may be interconnected, for example, by an internal bus.

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

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

The device 10 may be, for example, a personal computer (PC, e.g., desktop or laptop) 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, for example, by software (e.g., the program of the present invention) loaded onto the main memory.

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

Figure 2 shows an example 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, memory 102, bus 103, storage device 104, input device 105, output device 106, and communication device 107. Note that these are examples, and the hardware configuration of the device 10 is not limited to this 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 Figure 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 bus 103.

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.

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) via, 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, for example, as the communication unit 16.

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 below), 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). The memory 102 may also be, for example, a ROM (read-only memory).

The storage device 104 is also referred to as an auxiliary storage device, in contrast to the main memory (primary storage device). As mentioned above, the storage device 104 stores operating programs, 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 from and to the recording medium. The recording medium is not particularly limited and may be internal or external, and examples include HD (hard disk), CD-ROM, CD-R, CD-RW, MO, DVD, flash memory, and memory card. The storage device 104 may be, for example, a hard disk drive (HDD) or solid state drive (SSD) that integrates the recording medium and drive.

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

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 include a digitizer (touch panel, etc.), a keyboard, a mouse, a scanner, an imaging device, a microphone, a sensor, etc. The output device 106 is, for example, a display device (LED display, LCD display), a printer, a speaker, etc.

Next, an example of a virtual machine container control method (hereinafter simply referred to as a control method) of this embodiment will be described based on the flowchart in Figure 3. The control method of this embodiment is implemented, for example, as follows using the virtual machine container device 10 of Figure 1. Note that the control method of this embodiment is not limited to use with the virtual machine container device 10 of Figure 1.

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

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 application process (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 the determination determines 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 terminates (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 the determination determines 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 terminates (END).

The virtual machine container unit 11 may be generated, for example, by a hardware virtualization function (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 by separating a part of a running OS. When the virtual machine container unit 11 is generated by a hardware virtualization function, the virtual machine monitor unit 12, for example, uses the hardware virtualization function to obtain system calls generated by the application process. In this way, by using the virtual machine function provided by the hardware virtualization function, it is possible to trap the system calls without requiring software modifications. Furthermore, by using the virtual machine function provided by the hardware virtualization function, it is possible to trap the system calls without increasing the overhead during software execution.

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).

Here, we will explain applications and system calls. Applications run by calling functions from the kernel, which is the core of the OS. Such calls to the kernel are called system calls.

The virtual machine monitor unit 12 can also be considered a hypervisor. Specific processing by the virtual machine monitor unit 12 will be described in embodiment 2 below.

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, depending on the type of OS, the host OS kernel unit 14 and the OS kernel emulation unit 15 operate as described above. The system call control unit 13 is also called a dispatcher, for example, and may be part of the virtual machine monitor unit 12.

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

The following describes emulation by the OS kernel emulation unit 15. When the OS on which an application runs (hereinafter also referred to as the target OS) and the host OS provide the same functions but the interfaces of the functions differ, 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, the emulation executes one of the methods described below in (1) to (4), depending on the degree of difference between the interfaces.

(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.

(2) When the correspondence between the parameter value and its meaning when the system call is invoked is different The parameter value of the system call issued by the application is converted into the value expected by the host OS based on a conversion table or conversion rules.

(3) When the same function as the function provided by the target OS can be realized by combining functions provided by the host OS, the requested system call is converted into a series of system call invocations of the host OS in order to realize the function in 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.

(4) When the system calls of the host OS alone cannot provide the same functions as those provided by the target OS, a program for providing the same functions is implemented within the emulator or as an external component and used.

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 kernel emulation unit 15 is capable of emulation (S13), determine whether the OS kernel emulation unit 15 is capable of emulation. If the OS of the application differs from the OS of the host OS kernel unit 14 and it is determined that emulation by the OS kernel emulation unit 15 is not possible (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 not possible" refers to 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 or effort. According to this aspect, the system call can be executed even in the above-mentioned case. On the other hand, if, for example, 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, processing similar to step S15 may be executed.

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 determines that the incompatible part cannot be emulated, the system call control unit 13 may, for example, have the other device emulate the incompatible part of the system call and have the other device execute the incompatible part of the system call.

The invention of this embodiment provides the following advantages, for example:

(1) Resources, 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.

(2) Design Flexibility, etc. According to this embodiment, the degree of freedom in designing an application configured with multiple virtual machine containers is increased. For example, a web server can be configured as a container with Linux (registered trademark) as the OS, and a database can be configured as a container with Windows (registered trademark) as the OS. Furthermore, existing applications and commercially available applications can be executed in the container as is without modifying the application to be executed in the container or combining it with a library.

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

(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 is between OSs, which results in large overhead. However, communication between containers on the same host can be achieved by memory-to-memory copying. Therefore, according to this embodiment, communication between containers for different OSs is faster than in conventional virtual machine-based virtualization.

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

An example of the control method of this embodiment shown in Figure 3 will be described in more detail using Figures 4A and 4B. Figure 4A is a flowchart showing an example of executing a virtual machine container in the control method of this embodiment. First, as a preparation stage, steps S21 to S23 shown in Figure 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 using a hardware virtualization function. Step S22 is a step of setting the virtual machine container unit 11 to trap system calls. The system calls are generated by the application process loaded in step S23, which will be described later. Step S23 is a step of loading the application into the memory space of the virtual machine container unit 11. The application is then executed within the virtual machine container unit 11 (S24).

Next, steps S25 to S28 shown in FIG. 4A are executed as the execution stage of the virtual machine container unit 11. 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 issued by 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 could cause a problem in the system if the application were to be executed as is within the virtual machine container unit 11. More specifically, examples of the specific instruction include an instruction that requires special privileges or an instruction that accesses an unauthorized memory area. The application's attempt to execute the specific instruction is detected, for example, by a hardware virtualization function. Step S27 is a step of executing the instruction within 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 within 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, as described in FIG. 3, and the system call is executed (S29). Processing when the specific command is not a command related to a system call will be described later using FIG. 6. Execution of the virtual machine container in the control method of this embodiment ends (END) after, for example, either step S27 or step S29 is executed. In the control method of this embodiment, for example, after steps S27 and S29, processing may be repeated from step S25.

Figure 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, control related to the processing of the specific command is transferred to the virtual machine monitor unit 12, as described in Figure 4A. Next, in step S32, it is determined whether the transfer (hereinafter also referred to as control transfer) is due to 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 due to the system call (NO), the process proceeds to step S33.

Figure 6 is a flowchart showing an example of the processing of the virtual machine monitor unit 12 when the control transfer is not caused by the system call. Step S33, for example, includes steps S33-1 to S33-3 shown in Figure 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 determination result is that execution of the specific command is not permitted (NO), the virtual machine monitor unit 12, for example, returns an error to the application or terminates the application depending on the circumstances (step S33-2), and terminates (END). On the other hand, if the determination result is that execution of the specific command is permitted (YES), the virtual machine monitor unit 12, for example, returns control to the application in the virtual machine container unit 11, resumes execution of the specific command within the virtual machine container unit 11 (step S33-3), and terminates (END). More specifically, "permitting execution of the command" refers to, for example, granting special privileges or permitting access to a memory area when executing the command. Additionally, depending on the specific command that the application is attempting to execute, the virtual machine monitor unit 12 may execute the specific command in a safe manner and return the result to the application.

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 obtaining the OS type of the virtual machine container unit 11. Step S34 is executed, for example, by 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, for example, by the system call control unit 13. If it is determined that the OS is emulatable (YES), in step S38, control for the command is transferred to emulation by 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 incapable of emulation (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 for 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 incapable of remote execution (NO), in step S41, an error is returned to the process by the system call control unit 13. 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 executing step S36, step S38, or step S40, the execution result of the system call is returned to the process (S42). Then, the process ends (END).

We will now provide a more detailed explanation of virtual machine-based virtualization, container-based virtualization, and unikernel container-based virtualization, as well as the virtual machine container device 10 of this embodiment. Figure 5A is a schematic diagram showing an example of a virtualization environment and system call execution in virtual machine-based virtualization. Figure 5B is a schematic diagram showing an example of a virtualization environment and system call execution in container-based virtualization. Figure 5C is a schematic diagram showing an example of a virtualization environment and system call execution in unikernel container-based virtualization. Figure 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 Figures 5A to 5D, app is an abbreviation for application, and SVC is an abbreviation for system call (supervisor call). In the following explanation and Figures 5A to 5D, OS-A, OS-B, and OS-C refer to types of OS.

First, we will explain virtual machine-based virtualization using Figure 5A. In this example, as shown in Figure 5A (A), virtual machine 1 is built 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, guest OS kernel 3 receives a system call from application 2c. Guest OS kernel 3 executes hardware access, etc. When such hardware access, etc. is executed, the hardware virtualization function traps it, and control is transferred to virtual machine monitor 12A. Then, in virtual machine-based virtualization, the virtual machine monitor 12A executes the system call. As such, virtual machine-based virtualization requires the intervention of guest OS kernel 3, and as mentioned above, this requires many resources to run the guest OS, and startup takes time.

Next, container-based virtualization will be explained using Figure 5B. In this example, container 4 is constructed on a host OS (host OS kernel 14B), which is OS-A, and has application 2a for OS-A. Container 4 is created and operated by container runtime 5. In container-based virtualization, 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 as mentioned above, it is not possible to execute processing for a container that has an application for an OS different from the host OS.

Next, we will explain Unikernel container-based virtualization using Figure 5C. In this example, Unikernel container 6 is built on the 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-based virtualization, application 2c calls the kernel emulation library 7. The host OS kernel 14C then obtains a system call from the kernel emulation library 7 and executes the system call. The kernel emulation library 7 implements the system call functions 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 applications. As described above, in Unikernel container-based virtualization, a kernel emulation library 7 must be developed for each OS of application 2c.

Finally, the virtual machine container device 10 of this embodiment will be described using Figure 5D. In Figure 5D, the virtual machine containers 11A-C 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 virtual machine 8 correspond to the OS kernel emulation unit 15. In this example, the host OS type in the host OS kernel 14D is OS-A. Note that the present invention is not limited to this example.

First, we will explain using an example of a virtual machine container 11A that has application 2a for OS-A. The virtual machine monitor 12D obtains system calls generated by the process of application 2a within 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. The dispatcher 13D then 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.

Next, we will use an example of a virtual machine container 11B that has application 2b for OS-B. The virtual machine monitor 12D acquires a system call generated by the process of application 2b within 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, because the OS of application 2b is OS-B and the OS of the host OS kernel 14D is OS-A, 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. The host OS kernel 14D then executes the system call for OS-A. Furthermore, if dispatcher 13D determines that part of application 2b's OS is incompatible with the host OS, but the other parts are compatible, host OS kernel 14D may execute the compatible part of the system call. Meanwhile, OS kernel emulator 15D may emulate the incompatible part of the system call for OS-B into a system call for OS-A. Then, host OS kernel 14D executes the system call for the incompatible part emulated into the system call for OS-A. Note that kernel emulation library 7 in Figure 5C differs from OS kernel emulator 15D in that it implements only the OS functions required by the application, and in that it is executed in conjunction with the application and is called directly by the application.

Finally, we will use an example of a virtual machine container 11C containing application 2c for OS-C. The virtual machine monitor 12D intercepts system calls generated by the process of application 2c within the virtual machine container 11C. More specifically, 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, because application 2c's OS is OS-C and the host OS kernel 14D's OS is OS-A, the dispatcher 13D determines that application 2c's OS 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, for example, via the communication unit 16, causes another device 20 to emulate and execute the system call. The other device 20 has OS-C as its host OS (kernel). On the other hand, the dispatcher 13D may, for example, have a virtual machine 8 having OS-C as the guest OS 9 emulate the system call and execute the system call. In other words, the virtual machine 8 can also function as the OS kernel emulation unit 15.

[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 on, for example, 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.

The present invention has been described above with reference to the embodiments, but the present invention is not limited to the above embodiments. Various modifications that would 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.

<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 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.
(Appendix 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;
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 apparatus according to claim 1 or 2.
(Appendix 4)
The virtual machine container unit is generated by a hardware virtualization function.
4. The virtual machine container apparatus according to claim 1.
(Appendix 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.
(Appendix 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;
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 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.
(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 appendices 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 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.
(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 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;
10. The program according to claim 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 that emulation by the OS kernel emulation procedure is not possible, 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 according to any one of appendices 9 to 11.
(Appendix 13)
A computer-readable recording medium having recorded thereon the program according to any one of appendices 9 to 12.

This invention makes it possible to run containers for operating systems different from the host OS. Therefore, this invention is particularly useful, for example, when running applications in a container-based virtualization environment.

1, 8 Virtual Machines 2a, 2b, 2c Applications 3 Guest OS Kernel 4 Container 5 Container Runtime 6 Unikernel Container 7 Kernel Emulation Library 9 Guest OS
10 Virtual Machine Container Device 11 Virtual Machine Container Unit 11A, 11B, 11C Virtual Machine Container 12 Virtual Machine Monitor Unit 12A, 12D Virtual Machine Monitor 13 System Call Control Unit 13D Dispatcher 14 OS Host Kernel Unit 14A, 14B, 14C, 14D Host OS Kernel 15 OS Kernel Emulator Unit 15D OS Kernel Emulator 16 Communication Unit 20 Other Devices 101 Central Processing Unit 102 Memory 103 Bus 104 Storage Device 105 Input Device 106 Output Device 107 Communication Device

Claims (10)

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 execution result of the emulation to the process.
Virtual machine container device. 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 . 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. The virtual machine container unit is generated by a hardware virtualization function.
The virtual machine container device according to claim 1 . 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 result of the emulation to the process.
How to control virtual machine containers. 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. 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. 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. 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. 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 execution result of the emulation to the process;
The program according to claim 9.