WO2018173130A1

WO2018173130A1 - Virtual machine, and device driver update method

Info

Publication number: WO2018173130A1
Application number: PCT/JP2017/011324
Authority: WO
Inventors: 大田川
Original assignee: 株式会社日立製作所
Priority date: 2017-03-22
Filing date: 2017-03-22
Publication date: 2018-09-27

Abstract

This virtual machine comprises: an HBA 15; a hypervisor 100 having virtual HBA information 111, 113 that is associated with the HBA 15; and an LPAR 200. The LPAR 200 has: an HBA driver 241 (operational); an HBA driver 243 (for update); a driver switching control module 230 having virtual entry points 231, 233; and an OS kernel 220. The driver switching control module 230 performs switching control so that the OS kernel 220 is selectively connected to either the virtual entry point 231 or virtual entry point 243.

Description

Method for updating virtual machine and device driver

The present invention relates to a technology for updating a device driver with a virtual machine.

In order to control the host bus adapter (Host Bus Adapter: HBA) installed in the server, a host bus adapter driver (hereinafter, HBA driver) is installed in the server. This HBA driver is loaded on the memory when an OS (Operation System) is started, and controls the HBA.

When updating this HBA driver, after installing the new HBA driver, it is necessary to load the new HBA driver into the memory and replace it with the pre-update HBA driver already loaded into the memory. In order to replace the HBA driver on the memory, the OS is generally restarted. However, it is difficult to restart the OS in a mission critical system. Therefore, there is a high need for updating the HBA driver without restarting the OS, that is, replacing the HBA driver loaded on the memory.

For example, Patent Document 1 describes a technique for updating an HBA driver while maintaining a connection between a computer and a peripheral device. In the technique of Patent Document 1, the HBA driver is configured by a plurality of modules, the OS interface module and the hardware interface module are not changed, and only the driver module separated from the I / F is updated.

In recent years, technologies related to virtual servers obtained by virtualizing physical servers have been used. A technique for updating the HBA driver without stopping the OS is also required in the virtual server.

JP 2011-197868 A

A virtual computer according to an embodiment of the present invention includes an HBA (Host Bus Adapter), a hypervisor having a first virtual HBA and a second virtual HBA corresponding to the HBA, and an LPAR (LPAR) operating under the control of the hypervisor. (Logical PARtion). The LPAR is connected to the first HBA driver associated with the first virtual HBA, the second HBA driver associated with the second virtual HBA, and the first HBA driver. A switching control module having a first virtual entry point and a second virtual entry point connected to the second HBA driver, and an OS (Operation System) kernel. The switching control module performs switching control to determine whether the connection destination of the OS kernel is the first virtual entry point or the second virtual entry point.

The functional block diagram of the virtual computer system which concerns on one Embodiment of this invention. An example of the virtual HBA information management table 161 is shown. An example of the flag management table 261 is shown. An example of the entry point management table 263 is shown. The sequence of the update process of an HBA driver is shown. The functional block diagram of the virtual machine system after path switching. The functional block diagram of the virtual machine system which deleted the HBA driver (working) 241. The functional block diagram of the virtual computer system after updating to the HBA driver (current: new) 245.

Hereinafter, a virtual machine system according to an embodiment of the present invention will be described with reference to the drawings.

In the following description, the information of the present invention will be described using expressions such as “aaa table”, “aaa list”, “aaaDB”, “aaa queue”, etc., but these information are not necessarily limited to tables, lists, DBs, queues, It may be expressed by other than the data structure. Therefore, “aaa table”, “aaa list”, “aaaDB”, “aaa queue”, etc. may be referred to as “aaa information” to indicate that they are not dependent on the data structure.

Furthermore, in describing the contents of each information, the expressions “identification information”, “identifier”, “name”, “name”, and “ID” are used, but these can be replaced with each other.

In the following description, there is a case where “program” is used as the subject. However, since the program performs processing determined by being executed by the processor using the memory and the communication port (communication control device), the processor is used as the subject. The explanation may be as follows. Further, the processing disclosed with the program as the subject may be processing performed by a computer such as a management server or an information processing apparatus. Further, part or all of the program may be realized by dedicated hardware.

Various programs may be installed in each computer by a program distribution server or a storage medium that can be read by the computer. In this case, the program distribution server includes a CPU and storage resources, and the storage resources further store a distribution program and a program to be distributed. When the distribution program is executed by the CPU, the CPU of the program distribution server distributes the distribution target program to other computers.

Note that the server may have an input / output device. Examples of input / output devices include a display, a keyboard, and a pointer device, but other devices may be used. Also, as an alternative to the input / output device, a serial interface or an Ethernet interface is used as the input / output device, a display computer having a display or a keyboard or a pointer device is connected to the interface, and the display information is transmitted to the display computer. By receiving the input information from the display computer, the display computer may perform the display, or the input may be replaced by the input / output device by receiving the input.

A virtual computer according to an embodiment of the present invention includes an HBA (Host Bus Adapter), a hypervisor having a first virtual HBA and a second virtual HBA corresponding to the HBA, and an LPAR (Logical Logical) that operates under the control of the hypervisor. PARtion). The LPAR includes a first HBA driver associated with the first virtual HBA, a second HBA driver associated with the second virtual HBA, and a first virtual entry connected to the first HBA driver. A switching control module having a second virtual entry point connected to the point and the second HBA driver, and an OS (Operation System) kernel. The switching control module may perform switching control to determine whether the connection destination of the OS kernel is the first virtual entry point or the second virtual entry point.

The hypervisor may perform switching control of whether the connection destination of the HBA is the first virtual HBA or the second virtual HBA.

When the connection destination of the OS kernel is the first virtual entry point, when the first HBA driver obtains the I / O command from the OS kernel, the HBA is obtained via the first virtual HBA based on the I / O command. It may be operated.

The LPAR unloads the first HBA adapter driver after the driver switching control module switches the connection destination of the OS kernel from the first virtual entry point to the second virtual entry point, and loads the third HBA adapter driver. You may further have the update control utility to load.

After the driver switching control module switches the connection destination of the OS kernel from the first virtual entry point to the second virtual entry point, when the second HBA adapter driver acquires the I / O command from the OS kernel, the I / O The HBA may be operated via the second virtual HBA based on the command.

After the loading of the third HBA adapter driver is completed, the driver switching control module may switch the connection destination of the OS kernel from the second virtual entry point to the first virtual entry point.

FIG. 1 is a functional configuration diagram of the virtual machine system according to the present embodiment.

The virtual machine system has a server 1 and a storage device 7. The server 1 and the storage device 7 are connected via a network 9. The server 1 receives a read request of data stored in the storage device 7 and a data write request (I / O request) to the storage device 7 from a business computer (not shown). Based on this I / O request, the server 1 sends a data I / O command to the storage apparatus 7 to read / write data.

The server 1 includes a CPU (Central Processing Unit) 10, a memory 12, and an HBA (host bus adapter) 15.

The CPU 10 reads a predetermined computer program and operates the hypervisor 100 and a plurality of LPARs (Logical Partitions) 200 and 200 on the memory.

The hypervisor 100 is a virtualization mechanism that physically makes one server appear logically to a plurality of servers. The hypervisor 100 generates and controls the

LPARs

200 and 200. The hypervisor 100 includes

virtual HBA information

111 and 113, physical HBA information 130, and a virtual HBA information management table 161.

The physical HBA information 130 includes physical address information of the HBA 15. For example, the physical HBA information 130 includes a PCI memory space address and a configuration space address of the HBA 15. The physical HBA information 130 becomes an interface with the hardware HBA 15.

The

virtual HBA information

111 and 113 has address information for virtualizing the HBA 15 with respect to the LPAR 200. The hypervisor 100 may have a plurality of

virtual HBA information

111 and 113 for one LPAR 200. In FIG. 1, two pieces of HBA information # 1 for LPAR # 1 are prepared. The virtual HBA information 111 is used for the working path, and the virtual HBA information 113 is used for the update path. The working path and update path will be described later. The

virtual HBA information

111 and 113 are virtual HBAs for the LPAR 200.

The virtual HBA information management table 161 manages addresses included in the

virtual HBA information

111 and 113. The hypervisor 100 refers to the virtual HBA information management table 161 and identifies the address of the data transmission destination.

FIG. 2 shows an example of the virtual HBA information management table 161. As shown in the figure, the virtual HBA information management table 161 has a partition 1611, a PCI memory space address 1612, a config space address 1613, and a used path 1614 as data items.

The category 1611 indicates whether it is for current use or for update. Here, the virtual HBA information 111 corresponds to the current use, and the virtual HBA information 113 corresponds to the update.

The PCI memory space address 1612 is a PCI memory space address of each of the virtual HBAs for current use and update.

The config space address 1613 is a config space address of each of the virtual HBAs for current use and update.

The used path 1614 indicates which PCI memory space address 1612 and config space address 1613 for use and update are in use. In the usage path 1614, “1” indicates that it is in use.

The hypervisor 100 normally processes the I / O command received from the LPAR 200 using the current PCI memory space address 1612 and the config space address 1612, that is, the virtual HBA information 111. When updating the HBA driver, the hypervisor 100 processes the I / O command received from the LPAR 200 using the PCI memory space address 1612 and the configuration space address 1612 for updating, that is, the virtual HBA information 113.

Returning to FIG. 1, the LPAR 200 operates under the control of the hypervisor 100. Hereinafter, LPAR # 1 will be described, but the same applies to other LPARs.

In LPAR200, a guest OS operates. For example, the guest OS of the LPAR 200 includes an update control utility 210, an OS kernel 220, a driver update control module 230,

HBA drivers

241, 243,

virtual HBA information

251, 253, a flag management table 261, and entry point management. And a table 263.

FIG. 3 shows an example of the flag management table 261. As shown in the figure, the flag management table 261 has a flag name 2611 and a flag set value 2612 as data items. Here, the flag management table 261 stores whether the I / O command issuance suppression flag is ON or OFF (in the figure, the flag indicates “OFF”).

FIG. 4 shows an example of the entry point management table 263. As shown in the figure, the entry point management table 263 has a classification 2631, entry point information 2632, and a used path 2633 as data items. Here, the entry point management table 263 stores current and update entry points and information indicating which of the current and update entry points are in use. Here, the virtual entry point 231 corresponds to the current use, and the virtual entry point 233 corresponds to the update.

Returning to FIG. 1, the virtual HBA information 251 is virtual HBA information of the working path associated with the HBA driver (working) 241. The virtual HBA information 251 corresponds to the virtual HBA information 111 of the hypervisor 100. The virtual HBA information 253 is virtual HBA information of an update path associated with the HBA driver (for update) 243. The virtual HBA information 253 corresponds to the virtual HBA information 113 of the hypervisor 100.

The driver update control module 230 has a virtual entry point 231 and a virtual entry point 233. The virtual entry point 231 is a working virtual entry point associated with the HBA driver (working) 241. The virtual entry point 233 is an update virtual entry point associated with the HBA driver (for update) 243.

As a result, in the state shown in FIG. 1, in the LPAR 200, the virtual entry point 231-HBA driver (active) 241-virtual HBA information 251 indicates that the active path is virtual entry point 233-HBA driver (update) 243-virtual HBA information 253. The update path is configured.

The update control utility 210 updates the HBA driver 241. Details of the update processing of the HBA driver 241 will be described later.

The OS kernel 220 processes an I / O command for the storage apparatus 7 based on an I / O request from a business computer (not shown). For example, the OS kernel 220 sends an I / O command to the HBA driver (current) 241 or the HBA driver (update) 243 and obtains a response thereto. At this time, the OS kernel 220 refers to the entry point management table 263 and specifies the entry point of the transmission destination of the I / O command.

The OS kernel 220 normally refers to the entry point management table 263, identifies the current entry point information 2632 in which “1” is set in the use path 2633, and sends an I / O command to the current virtual entry point 231. Send to. That is, the OS kernel 220 is normally connected to the working path via the entry point 221 and the virtual entry point 231. On the other hand, during the update process of the HBA driver, the OS kernel 220 refers to the entry point management table 263, specifies the entry point information 2632 for update in which “1” is set in the use path 2633, and The / O command is transmitted to the virtual entry point 233 for update. That is, the OS kernel 220 is connected to the update path via the entry point 221 and the virtual entry point 233 during the HBA driver update process.

The driver update control module 230 controls pre-processing and post-processing for updating the HBA driver (current) 241. For example, the driver update control module 230 switches the transmission destination of the I / O command from the virtual entry point 231 to the virtual entry point 233, or from the virtual entry point 233 to the virtual entry point 231. The driver update control module 230 instructs the hypervisor 100 to switch the virtual HBA. For example, the driver update control module 230 instructs whether to switch the connection destination of the HBA 15 from the virtual HBA information 111 to the virtual HBA information 113 or from the virtual HBA information 113 to the virtual HBA information 111.

The HBA driver (current) 241 and the HBA driver (update) 243 operate the HBA 15 according to the I / O command acquired from the OS kernel 220 to transmit / receive data to / from the storage apparatus 7.

The HBA driver (working) 241 is an HBA driver incorporated in the working path. The HBA driver (working) 241 acquires and processes an I / O command sent from the OS kernel 220 to the virtual entry point 231 during normal operation. The HBA driver (active) 241 sends an I / O command to the hypervisor 100 using the virtual HBA information 251.

The HBA driver (for update) 243 is an HBA driver incorporated in the update path. The HBA driver (for update) 243 acquires and processes the I / O command sent from the OS kernel 220 to the virtual entry point 233 during the update process. The HBA driver (for update) 243 uses the virtual HBA information 253 to send an I / O command to the hypervisor 100.

The HBA driver (current) 241 and the HBA driver (update) 243 may have equivalent functions.

FIG. 5 shows an update processing sequence of the HBA driver. A process for updating the HBA driver (active) 241 from the state shown in FIG. 1 will be described with reference to FIG.

First, the update control utility 210 instructs the driver update control module 230 to start the HBA driver update process (S101). Thereby, a series of HBA driver update processing is started. As a pre-process for updating the HBA driver body, a path switching process (from the current path to the update path) is performed.

Upon receiving a driver update process start instruction from the update control utility 210, the driver update control module 230 stops issuing a new I / O command to the HBA driver (active) 241 and performs an I / O command in the flag management table 261. The set value 2612 of the issue suppression flag is turned ON (S201). When all the I / O commands being executed are completed (S203: Yes), the driver update control module 230 instructs the hypervisor 100 to switch the virtual HBA (S205).

The hypervisor 100 switches the virtual HBA in response to this switching instruction (S301). That is, the hypervisor 100 sets “0” indicating non-use to the current use path 1614 of the virtual HBA information management table 161 and sets “1” indicating use to the update use path 1614. As a result, the virtual HBA information used by the hypervisor 100 for the LPAR 200 is switched to the virtual HBA information 113. That is, the physical HBA information 130 is connected to the update path. The hypervisor 100 notifies the driver update control module 230 of the completion of switching of the virtual HBA (S303).

Next, the driver update control module 230 switches entry points (S207). That is, the driver update control module 230 sets “0” indicating non-use to the current use path 2633 of the entry point management table 263 and sets “1” indicating use to the update use path 2633. As a result, the virtual entry point used by the OS kernel 220 is switched to the virtual entry point 233. That is, the driver update control module 230 is connected to the update path.

The switch from the working path to the update path is completed by the process so far. FIG. 6 shows a state where the path is switched.

Returning to FIG. 5, the driver update control module 230 turns off the setting value 2612 of the I / O command issuance suppression flag in the flag management table 261, restarts the processing that has been stopped using the update path, Issue an I / O command (S209). The driver update control module 230 notifies the update control utility 210 of completion of the path switching process (S211).

The update control utility 210 unloads the HBA driver (working) 241 from the LPAR 200 after completing the path switching (S103). FIG. 7 shows a state where the HBA driver (working) 241 is unloaded.

After unloading the HBA driver (current) 241, the update control utility 210 loads a new HBA driver (current: new) 245 into the LPAR 200 (S 105). As a result, the HBA driver (current) 241 to be updated is unloaded from the memory 12, and a new HBA driver (current: new) 245 is loaded. Thus, the HBA driver main body is updated from the HBA driver (current) 241 to the HBA driver (current: new) 245.

When the update process of the HBA driver main body is completed, the update control utility 210 instructs the driver update control module 230 to end the HBA driver update process (S107). As a result, a path switching process (from the update path to the working path) is performed as post-processing for updating the HBA driver body.

When receiving an instruction to end the driver update process from the update control utility 210, the driver update control module 230 stops issuing a new I / O command and sets the I / O command issue suppression flag set value 2612 in the flag management table 261. Is turned ON (S213). When all the I / O commands being executed are completed (S215: Yes), the driver update control module 230 instructs the hypervisor 100 to switch the virtual HBA (S217).

The hypervisor 100 switches the virtual HBA in response to this switching instruction (S305). That is, the hypervisor 100 sets “0” indicating non-use to the update use path 1614 of the virtual HBA information management table 161, and sets “1” indicating use to the current use path 1614. As a result, the virtual HBA information used by the hypervisor 100 for the LPAR 200 is switched to the virtual HBA information 111. That is, the physical HBA information 130 is connected to the working path. The hypervisor 100 notifies the driver update control module 230 of the completion of switching of the virtual HBA (S307).

Next, the driver update control module 230 switches entry points (S219). Here, the driver update control module 230 sets “0” indicating non-use in the update use path 2633 of the entry point management table 263 and sets “1” indicating use in the current use path 2633. As a result, the virtual entry point used by the OS kernel 220 is switched to the virtual entry point 231. That is, the driver update control module 230 is connected to the working path.

The driver update control module 230 turns off the setting value 2612 of the I / O command issuance suppression flag in the flag management table 261, restarts the processing that has been stopped using the working path, and processes the new I / O command. Is issued (S221). As a result, the I / O command processing using the updated HBA driver (current: new) 245 is performed.

The driver update control module 230 notifies the update control utility 210 of the end of the HBA driver update process (S223).

The switching from the HBA driver (current) 241 to the HBA driver (update) 243 is completed by the above processing. FIG. 8 shows a state where the path is switched.

This makes it possible to update the HBA driver without restarting the OS in the virtual machine system.

The embodiments of the present invention described above are examples for explaining the present invention, and are not intended to limit the scope of the present invention only to those embodiments. Those skilled in the art can implement the present invention in various other modes without departing from the gist of the present invention.

1 server 15 HBA
100

Hypervisor

111, 113 Virtual HBA information 130 Physical HBA information 200 LPAR
210 Update control utility 220 OS kernel 221 Entry point 230 Driver

update control module

231, 233

Virtual entry point

241, 243

HBA driver

251, 253 Virtual HBA information

Claims

HBA (Host Bus Adapter),
A hypervisor having a first virtual HBA and a second virtual HBA corresponding to the HBA;
A virtual machine having an LPAR (Logical PARTION) operating under the control of the hypervisor,
The LPAR is
A first HBA driver associated with the first virtual HBA;
A second HBA driver associated with the second virtual HBA;
A switching control module having a first virtual entry point connected to the first HBA driver and a second virtual entry point connected to the second HBA driver;
An OS (Operation System) kernel,
The switching control module is a virtual computer that performs switching control of whether the connection destination of the OS kernel is the first virtual entry point or the second virtual entry point.
The virtual machine according to claim 1, wherein the hypervisor performs switching control of whether the connection destination of the HBA is the first virtual HBA or the second virtual HBA.
When the connection destination of the OS kernel is the first virtual entry point, when the first HBA driver acquires an I / O command from the OS kernel, the first virtual entry point is based on the I / O command. The virtual computer according to claim 1, wherein the HBA is operated via an HBA.
The LPAR is
The driver switching control module switches the connection destination of the OS kernel from the first virtual entry point to the second virtual entry point, and then unloads the first HBA adapter driver and outputs a third HBA adapter. The virtual machine according to claim 1, further comprising an update control utility for loading a driver.
After the driver switching control module switches the connection destination of the OS kernel from the first virtual entry point to the second virtual entry point, the second HBA adapter driver sends an I / O command from the OS kernel. The virtual computer according to claim 4, wherein upon acquisition, the HBA is operated via the second virtual HBA based on the I / O command.
The driver switching control module switches the connection destination of the OS kernel from the second virtual entry point to the first virtual entry point after the loading of the third HBA adapter driver is completed. Virtual computer.
A method for updating a device driver in a virtual machine,
The virtual machine is
HBA (Host Bus Adapter),
A hypervisor having a first virtual HBA and a second virtual HBA corresponding to the HBA;
A first path configured by connecting the first virtual HBA, a first HBA driver, and a first virtual entry point; the second virtual HBA; and a second HBA driver; A second path formed by connecting the second virtual entry point, and an OS (Operation System) kernel, and an LPAR (Logical Partition) operated by the control of the hypervisor. And
When the connection destination of the OS kernel is the first virtual entry point, the OS kernel issues an I / O command to the first path and operates the HBA using the first HBA driver. Steps,
Stopping issuing I / O commands from the OS kernel and switching the connection destination of the OS kernel to the second virtual entry point;
When the connection destination of the OS kernel is the second virtual entry point, the OS kernel issues an I / O command to the second path and operates the HBA using the second HBA driver. Steps,
Unloading the first HBA driver and loading a third HBA driver when the OS kernel is connected to the second virtual entry point;
Stopping issuing I / O commands from the OS kernel and switching the connection destination of the OS kernel to the first virtual entry point;
When the connection destination of the OS kernel is the first virtual entry point, the OS kernel issues an I / O command to the first path and operates the HBA using the third HBA driver. Step and how to do.