WO2018092287A1 - 計算機及び計算機の再起動方法 - Google Patents

計算機及び計算機の再起動方法 Download PDF

Info

Publication number
WO2018092287A1
WO2018092287A1 PCT/JP2016/084370 JP2016084370W WO2018092287A1 WO 2018092287 A1 WO2018092287 A1 WO 2018092287A1 JP 2016084370 W JP2016084370 W JP 2016084370W WO 2018092287 A1 WO2018092287 A1 WO 2018092287A1
Authority
WO
WIPO (PCT)
Prior art keywords
management
virtual
hypervisor
port
computer
Prior art date
Application number
PCT/JP2016/084370
Other languages
English (en)
French (fr)
Inventor
幸太郎 横山
良太 野口
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to PCT/JP2016/084370 priority Critical patent/WO2018092287A1/ja
Publication of WO2018092287A1 publication Critical patent/WO2018092287A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10—Program control for peripheral devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements

Definitions

  • the present invention relates to a computer and a computer restart method, and is particularly suitable for application to a computer having a virtual computer using a virtual port.
  • SR-IOV Single Root I / O Virtualization
  • PF Physical Function
  • VF Virtual Function
  • the driver When the driver is updated, the driver is reinitialized.
  • the PF When the PF is reset, all the VFs generated from the reset PF are lost, and the virtual machine to which the lost VF is assigned is also affected. Therefore, conventionally, when resetting a PF, the virtual machine is stopped, and then the PF is reset and the VF is regenerated and reassigned.
  • JP 2012-203636 A In order to respond to such a request, as a technology for restoring a VF without stopping the guest OS running on the virtual machine when an I / O failure occurs, there is a publicity of JP 2012-203636 A (see Patent Document 1). .
  • a hot-plugging (hot-removing) device is removed by using HotPlug (a technology for inserting / removing a device while the server is operating), and the operating guest is installed (hotadd) after the device is restored.
  • HotPlug a technology for inserting / removing a device while the server is operating
  • the operating guest is installed (hotadd) after the device is restored.
  • the VF can be restored without stopping the OS (see Patent Document 1).
  • VF parameters include a MAC address, VLAN ID, TxRate, and the like.
  • the present invention can be used in the same way when the driver is updated. Since the value of the VF parameter is set according to the system to be configured, if the setting is changed before and after the recovery, there is a possibility of causing a communication disabled state and a performance problem.
  • the present invention has been made in view of the above points, and proposes a computer that can be restarted in the same operating state using the same parameters before and after the reset, and a computer restart method. It is what.
  • an I / O adapter that includes a physical port and that generates at least one virtual port that corresponds to the physical port and operates according to a set parameter value; At least one virtual machine that operates a guest operating system that communicates with the outside using the I / O adapter by accessing at least one virtual port; the at least one virtual machine; and the I / O A management virtual machine that manages the O adapter, and a hypervisor that holds the parameter information including the parameter value set in the at least one virtual port in a non-volatile manner. The parameter based on the parameter information acquired from the hypervisor. Set again the meter value to the at least one virtual port, characterized in that to re-recognize the assignment the guest operating system of the at least one virtual port to said at least one virtual machine.
  • an I / O adapter that includes a physical port, and that generates at least one virtual port that corresponds to the physical port and operates according to a set parameter value, and the at least one virtual port And managing at least one virtual machine on which a guest operating system that exchanges with the outside using the I / O adapter operates, and the at least one virtual machine and the I / O adapter.
  • a restart method in a computer comprising: a management virtual machine; and a hypervisor that nonvolatilely stores parameter information including parameter values set in the at least one virtual port, wherein the management virtual machine is Obtain the parameter information from the hypervisor A parameter information obtaining step, a resetting step in which the management virtual machine resets the parameter value based on the parameter information in the at least one virtual port, and the management virtual machine has the at least one virtual port. Is assigned to the at least one virtual machine, and the guest operating system recognizes again.
  • FIG. 1 shows a configuration example of the physical computer 10 according to the present embodiment.
  • the physical computer 10 is connected to the user terminal 600 via the third bridge 83.
  • the user terminal 600 passes through the first CPU 70-1 and the like and the third bridge 83 in the physical computer 10 and the physical computer via the fourth I / O adapter 93. 10 is connected.
  • the physical computer 10 includes a first CPU 70-1, a second CPU 70-2,..., And an Nth CPU 70-N as a plurality of central processing units.
  • N is a natural number.
  • the first bridge 80 is connected to the first I / O adapter 90 and the second I / O adapter 91.
  • the second bridge 81 is connected to the third I / O adapter 92.
  • the first virtual machine 30-1 to the Nth virtual machine 30-N, the management virtual machine 50, and the management virtual machine 50 are controlled.
  • the hypervisor 20 is operating.
  • the hypervisor 20 is loaded into the memory 100.
  • the first virtual machine 30-1 to the Nth virtual machine 30-N are controlled by the hypervisor 20.
  • the first guest OS 40-1 is executed, and in the Nth virtual machine 30-N, the second guest OS 40-N is executed.
  • the hypervisor 20 manages the management guest OS 60 executed in the management virtual machine 50.
  • the management guest OS 60 manages the first virtual machine 30-1 to the Nth virtual machine 30-N and the first I / O adapter 90 to the third I / O adapter 92. Details of the hypervisor 20 will be described later.
  • FIG. 2 shows an example of functions in the virtual machine system according to this embodiment.
  • the virtual machine system according to the present embodiment includes a first guest OS 40-1 to an Nth guest OS 40-N, a first virtual machine 30-1 to an Nth virtual machine 30-N, a hypervisor 20, and a management guest. It has an OS 60, a management virtual machine 50, a first I / O adapter 90, a second I / O adapter 91,..., A third I / O adapter 92.
  • the first to third I / O adapters 90 to 92 have a so-called SR-IOV function.
  • VFs 210 and 211 are generated from the PF 200 (corresponding to PF 1 shown in the figure).
  • VFs 212 and 213 are generated from the PF 201 (corresponding to the PF 2 shown in the figure).
  • VFs 214 and 215 are generated from the PF 202 (corresponding to the PF 3 shown in the figure).
  • two VFs are generated from each PF, but this embodiment can be applied regardless of the number of VFs generated.
  • the management virtual machine 50 includes assigned PFs 200 (corresponding to PF1 shown) to PF202 (corresponding to PF3 shown).
  • the management guest OS 60 includes a PF driver 240 corresponding to the type of PF 200 to PF 202.
  • the PF driver 240 of the management guest OS 60 has a function of generating the VF 210 and the like.
  • the first virtual machine 30-1 to the Nth virtual machine 30-N include the assigned VF 210 and the like.
  • the first guest OS 40-1 to the Nth guest OS 40-N include a VF driver 250 corresponding to the type of the VF 210 of the first virtual machine 30-1 to the Nth virtual machine 30-N.
  • the virtual machine emulation data 220-1 to 220-N holds management information indicating the bus number, device number, function number, and blocking status of the PF 200, such as the VF 210.
  • Blocking refers to blocking access from a virtual machine to a blocked device when a failure occurs.
  • the time when a failure occurs is mainly exemplified, but it goes without saying that it may be applied at the time of updating.
  • the first virtual machine emulation data 220-1 to the Nth virtual machine emulation data 220-N of the first virtual machine 30-1 to the Nth virtual machine 30-N, and The first VF parameter information 230-1 to the Kth VF parameter information 230-K are held in a nonvolatile manner. Details of the emulation data 220-1 of the first virtual machine to the emulation data 220-N of the Nth virtual machine will be described later. On the other hand, the first VF parameter information 230-1 to the Kth VF parameter information 230-K include parameters such as each VF210.
  • FIG. 3 is a block diagram showing a configuration example of the PF and VF in the first to third I / O adapters 90 to 92.
  • a PF 200 and a PF 201 are connected to the first bridge 80 under the control. From PF200, VF210 (corresponding to “VF0” in the figure) and VF211 (corresponding to “VF1” in the figure) are generated. VF201 to VF212 (corresponding to “VF0” in the figure) and VF213 (corresponding to “VF1” in the figure) are generated.
  • a PF 202 is connected to the second bridge 81. From this PF 202, a VF 214 (corresponding to “VF0” shown) and a VF 215 (corresponding to “VF1” shown) are generated.
  • the PFs including the VFs under the PF to be closed are closed.
  • the PFs 210 and 211 under the PF 200 are simultaneously blocked.
  • the device under the PF is blocked, but the bridge may be blocked or the VF alone may be blocked.
  • FIG. 4 shows an example of emulation data 220-1 to 220-N of virtual machines created by the hypervisor 20 in the configuration shown in FIG. Note that the emulation data 220-1 to 220-N is a part of a large list, and it is possible to specify a block target by specifying a bus. These emulation data 220-1 to 220-N of the virtual machines indicate device management information held by the hypervisor 20. Each row corresponds to management information of each device.
  • the device type 400 represents the type of each device.
  • Bus # 410, Dev # 420, and Func # 430 are unique values defined in the PCI specification within a total 16-bit system, and are used to uniquely identify a device within the physical computer 10.
  • PF # 440 is a PF number to which the device belongs. When the device type 400 is “PF”, it holds its own PF number, while when the device type 400 is “VF”, it holds the generation source PF number.
  • VF # 450 indicates the serial number of the VF in the generation source PF.
  • the device type 400 is “PF”, it does not have VF # 450.
  • Blocked state # 460 is management information indicating whether or not the device is blocked.
  • blocking means blocking access to a device from a virtual machine. For example, when a failure occurs in the device, the device is blocked because there is a possibility that a different failure is induced by continuing to use the device in which the failure has occurred.
  • FIG. 5 is a configuration example of the VF parameter information 230-1 to 230-K.
  • LPAR # 500 indicates the number of the virtual machine to which the VF is assigned.
  • PBus # 510, PFDev # 520, and PFFunc # 530 indicate the Bus number, Device number, and Function number of the PF generation source PF.
  • the hypervisor 20 can uniquely identify a VF using a combination of PFBus # 510, PFDev # 520, PFFunc # 530, and VF # 450.
  • the MAC address 540, VLAN ID 550, and TxRate 560 are parameters that each VF has individually.
  • the hypervisor 20 manages parameters for all VFs using the VF parameter information 230-1 to 230-K.
  • FIG. 6 is a sequence chart showing a flow from the occurrence of a failure to VF recovery in this embodiment. Steps S611 to S615 correspond to removal during operation (HotRemove), and Step S625 corresponds to attachment during operation (HotAdd).
  • the failure notification in step S610 is notified from the management guest OS 60 to the hypervisor 20; however, the recovery processing is performed when the hypervisor 20 itself detects the failure due to the cause of the failure.
  • this embodiment can be used not only when a failure occurs but also for restoration of PF and VF by online update of a driver or the like. When the driver is updated, the driver needs to be re-initialized. Therefore, as in the case of a failure, it is necessary to perform processing for once closing the device and re-recognizing it.
  • step S610 the management guest OS 60 notifies the hypervisor 20 of a failure.
  • step S611 the hypervisor 20 that has received the failure notification shifts to a blocking process.
  • step S612 the hypervisor 20 sends a PF blocking process request to the management guest OS 60.
  • step S613 the hypervisor 20 sends a VF blocking process request to each of the first guest OS 40-1 to the Nth guest OS 40-N.
  • step S614 the first guest OS 40-1 to the Nth guest OS 40-N change the blocked state 460 managed in the virtual machine emulation data 220-1 to 220-N (see FIG. 2) to the blocked state.
  • step S615 the hypervisor 20 sends a device re-recognition processing request to the first guest OS 40-1 to the Nth guest OS 40-N, and the first guest OS 40-1 to the Nth guest OS 40-N By re-searching the device recognized by itself, the recognition of the VF 210 (corresponding to the illustrated VF 10) is canceled.
  • step S616 the hypervisor 20 performs a termination process on the VF 210, whereby the VF 210 is reset.
  • step S617 the hypervisor 20 waits until the PF 200 is released from the management guest OS 60, and then performs an end process to reset the PF 200.
  • step S618 the hypervisor 20 notifies the user terminal 600 that the device has been blocked.
  • the user terminal 600 instructs the hypervisor 20 to request recovery processing at an arbitrary timing (step S619).
  • the hypervisor 20 sends a restart command to the management guest OS 60 of the management virtual machine 50 in response to the request for the recovery process (step S620).
  • step S621 after the management guest OS 60 is restarted in the management virtual machine 50, the loading of the PF driver 240 is started. Thereafter, it is determined whether or not the SR-IOV function is valid.
  • the management guest OS 60 confirms the settings of the first to third I / O adapters 90, 91, and 92 while the PF driver 240 is being loaded, and is a so-called SR-IOV compatible I / O adapter. That is, when the SR-IOV function is valid, the PF driver is incorporated using the activation option. Thereby, the PF driver is loaded and the VF is actually generated. On the other hand, when the SR-IOV function is not valid, only the PF driver is incorporated without using the validation option.
  • step S623 the hypervisor 20 sends a VF setting request to the effect that a parameter value should be set for each VF 210 and the like to the management guest OS 60.
  • the management guest OS 60 acquires the VF parameter information 230-1 to 230-K from the hypervisor 20 upon receipt of this VF setting request, and sets various parameters for each VF 210 and the like (step S624).
  • the hypervisor 20 sends a device re-recognition processing request to the first guest OS 40-1 to the Nth guest OS 40-N, so that the first guest OS 40-1 to the Nth guest OS 40-N are VF210. Is re-recognized to restore the VF 210 and the like (step S625).
  • the VF 210 and the like can operate using the various parameter values.
  • FIG. 7 shows an example of the blocking process executed in steps S611 to S617 shown in FIG.
  • step S700 an off-line request is sent to all VFs under the PF to which the faulted PF and VF belong.
  • This offline request is a request for stopping access from the guest OS 40-1.
  • the hypervisor 20 does not return a response to the device even if access is made from any of the first guest OS 40-1 to the Nth guest OS 40-N. That is, the hypervisor 20 performs control so as not to receive the access.
  • the hypervisor 20 gives a predetermined interrupt to any of the first guest OS 40-1 to the Nth guest OS 40-N, when the guest OS searches for a device that can be used by the guest OS, The stopped device cannot be recognized, and the device does not return a response to access (hot plug process). Such processing may be performed at startup.
  • step S701 the hypervisor 20 sets the blocking state 460 of the blocking target PF and VF in the emulation data 220-1 to 220-N shown in FIG. 4 to “blocking”.
  • the blocked state 460 is set to “blocked” in this way, the hypervisor 20 returns that it cannot respond to the PCIConfig access by the first guest OS 40-1 to the Nth guest OS 40-N.
  • the first guest OS 40-1 to the Nth guest OS 40-N are in a state where they can recognize that the device has disappeared in the device re-recognition processing step S615 described above.
  • step S702 the hypervisor 20 sends a device re-recognition processing request to the guest OS 40-1, and the guest OS 40-1 re-searches the logical device, whereby the recognition of the VF 210 is released.
  • step S703 the hypervisor 20 waits until processing for the offline request sent in step S700 is completed.
  • step S704 the hypervisor 20 requests termination processing for all the VFs under the bridge to be blocked, thereby resetting the VF 210 and the like.
  • the device is stopped by stopping DMA transfer, interrupting, and suppressing ErrorReport.
  • step S705 the hypervisor 20 requests termination processing for all the PFs under the bridge to be blocked, thereby resetting the PF 200 and the like.
  • the operation of the end process is the same as that in step S704 described above.
  • FIG. 8 is a flowchart of the VF generation process performed in steps S619 to S622 shown in FIG.
  • step S800 the hypervisor 20 issues a restart command to the management guest OS 60.
  • step S801 the management guest OS 60 is restarted.
  • step S802 when the hypervisor 20 restarts the management guest OS 60, the hypervisor 20 determines whether SR-IOV is set to be valid in the first to third I / O adapters 90, 91, and 92.
  • step S803 if it is determined in step S802 that SR-IOV is a valid I / O adapter in first to third I / O adapters 90, 91, 92, hypervisor 20 enables SR-IOV.
  • a PF driver 240 is incorporated using an option, and a VF 210 and the like are generated. Note that the processing in step S803 differs depending on the type of device, and a VF may be generated by performing settings after loading of the PF driver is completed.
  • step S804 if it is determined in step S802 that the SR-IOV is not valid, the hypervisor 20 incorporates the PF driver 240 without using the SR-IOV activation option.
  • FIG. 9 shows an example of the VF resetting process executed in steps S618 to S624 shown in FIG.
  • the management guest OS 60 acquires the VF parameter information 230-1 and the like from the hypervisor 20.
  • the management guest OS 60 uses the PF driver 240 to set VF parameters.
  • step S902 the management guest OS 60 determines whether or not a timeout has occurred regarding the setting of the VF parameter in step S901. When the timeout does not occur, the management guest OS 60 performs VF parameter result confirmation processing. On the other hand, when a timeout occurs, the management guest OS 60 determines that the setting of the VF parameter has failed, and notifies the hypervisor 20 that the setting has failed.
  • step S903 the management guest OS 60 compares the settings of the VF parameter information 230-1 and the VF 210, and notifies the hypervisor 20 of the completion of setting if there is no error in the parameters.
  • step S904 the management guest OS 60 notifies the hypervisor 20 of the result of the VF parameter setting. Further, the management guest OS 60 performs device reconfirmation processing on the first guest OS 40-1. As a result, the guest OS 40-1 can recognize the device. For this reason, the guest OS 40-1 can recognize and use each VF.
  • the management virtual computer 50 has at least one parameter value based on the parameter information acquired from the hypervisor 20 at the time of restart.
  • the virtual ports 210 and 211 are set again, the at least one virtual port 210 and 211 is assigned to at least one virtual machine 30-1 to 30-N, and the guest operating systems 40-1 to 40-N recognize again. I am letting you.
  • the virtual port can be used using the same VF parameter value before and after the reset, and can be operated in the same operating state.
  • the present invention can be widely applied to a computer having a virtual computer using a virtual port and a computer restart method.
  • 10 Physical computer
  • 20 Hypervisor, 30-1 to 30-N: Virtual computer
  • 40-1 to 40-N First to Nth guest OS
  • 50 Management virtual computer
  • 60 guest OS for management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Debugging And Monitoring (AREA)

Abstract

【課題】Ｉ／Ｏアダプタに障害が起きた場合やドライバ等のアップデートを行う際に、ゲストＯＳを停止させずにＩ／Ｏアダプタを復旧させる必要がある場合でも、Ｉ／Ｏアダプタのリセット前とリセット後とで同一のＶＦパラメータを利用して同一の作動状態でゲストＯＳが再起動できるようにすること。 【解決手段】復旧処理時にＶＦの管理を行う管理用仮想計算機が、ハイパバイザが持つＶＦパラメータの値を取得する。管理用仮想計算機は、受け取ったＶＦパラメータ情報を用いてＶＦを設定する。その後、管理用仮想計算機はＶＦパラメータ設定の結果確認を行い、ハイパバイザに対して結果の通知を行う。そして、再設定したＶＦを仮想計算機に対して動的に割り当て、ゲストＯＳに再認識させることでゲストＯＳを停止することなくＶＦを復旧することができる。

Description

計算機及び計算機の再起動方法
　本発明は、計算機及び計算機の再起動方法に関し、特に、仮想ポートを利用する仮想計算機を有する計算機に適用して好適なものである。
　近年、物理計算機が有するハイパバイザなどの仮想化機構により、物理計算機上に１つまたは複数の仮想計算機を構築する仮想計算機システムが広く使われている。その一方、仮想化環境でのＰＣＩデバイスのパフォーマンス向上のため、ハードウェア側で仮想化を支援する規格であるＳＲ－ＩＯＶ（Ｓｉｎｇｌｅ　Ｒｏｏｔ　Ｉ／Ｏ　Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）も広く使われている。ＳＲ－ＩＯＶは、１つの物理ポート（以下、ＰＦ：Ｐｈｙｓｉｃａｌ　Ｆｕｎｃｔｉｏｎ）をハードウェア的に仮想化し、仮想計算機に対して仮想ポート（以下、ＶＦ：Ｖｉｒｔｕａｌ　Ｆｕｎｃｔｉｏｎ）を提供する。ＳＲ－ＩＯＶ対応Ｉ／Ｏアダプタに障害が発生した時は、Ｉ／Ｏアダプタにハードウェアリセットを実施する。また、ドライバ更新時はドライバの再初期化を実施する。ＰＦのリセットを行った場合、リセットしたＰＦから生成されていたＶＦが全て消失してしまい、当該消失したＶＦが割り当てられていた仮想計算機にも影響が生ずる。そのため、従来はＰＦのリセットを行う場合は仮想計算機を停止してから、ＰＦのリセットおよびＶＦの再生成、再割り当てを行っていた。
　しかしながら、システムの特性から停止させることが難しい仮想計算機も存在するため、ＶＦが割り当てられた仮想計算機を停止せずにＩ／Ｏアダプタを安全に復旧したいという要求がある。
　このような要求に対応するため、Ｉ／Ｏ障害発生時に仮想計算機上で稼動するゲストＯＳを停止させずにＶＦを復旧させる技術として、特開２０１２－２０３６３６号広報がある（特許文献１参照）。この従来技術では、ＨｏｔＰｌｕｇ（サーバ稼働中にデバイスを抜き差しする技術）を用いて、障害発生デバイスを稼働時抜去（ＨｏｔＲｅｍｏｖｅ）し、デバイス復旧後に稼働時取り付け（ＨｏｔＡｄｄ）することで、稼働中のゲストＯＳを停止させずにＶＦを復旧させることができる（特許文献１参照）。
特開２０１２－２０３６３６号公報
　しかしながら、上述した従来技術では、Ｉ／Ｏアダプタの復旧時のＶＦパラメータの再設定の方法について想定されていない。ＶＦは、物理Ｉ／Ｏアダプタと同様にパラメータが設定されており、各ＶＦが異なるパラメータを保持している。ＶＦのパラメータとしては、ＭＡＣアドレス、ＶＬＡＮ　ＩＤ、ＴｘＲａｔｅなどが存在する。ＰＦのリセットに伴いＶＦが消失した場合、ＶＦに割り当てていた設定も消失してしまう。そのため、再設定を行わずに割り当てを行うと、障害発生前または更新前で異なる設定によってＶＦを仮想計算機に割り当てる可能性がある。以降は、障害時の場合のみ記述するが、ドライバ更新時も同様に本発明を用いることができる。ＶＦのパラメータは構成するシステムに応じて値が設定されるため、復旧前後で設定が変わると通信不可状態及び性能問題を引き起こす可能性がある。
　本発明は以上の点を考慮してなされたもので、リセット前とリセット後とで同一のパラメータを利用して同一の作動状態で再稼働することができる計算機及び計算機の再起動方法を提案しようとするものである。
　かかる課題を解決するため、本発明においては、物理ポートを備える一方、前記物理ポートに対応しており設定済みのパラメータ値に従って動作する少なくとも１つの仮想ポートが生成されるＩ／Ｏアダプタと、前記少なくとも１つの仮想ポートに対してアクセスすることによって前記Ｉ／Ｏアダプタを用いて外部とのやり取りを行うゲストオペレーティングシステムが動作する少なくとも１つの仮想計算機と、前記少なくとも１台の仮想計算機及び前記Ｉ／Ｏアダプタを管理する管理用仮想計算機と、前記少なくとも１つの仮想ポートに設定済みのパラメータ値を含むパラメータ情報を不揮発的に保持するハイパバイザと、を備え、前記管理用仮想計算機は、再起動時に前記ハイパバイザから取得した前記パラメータ情報に基づく前記パラメータ値を前記少なくとも１つの仮想ポートに再度設定し、前記少なくとも１つの仮想ポートを前記少なくとも１台の仮想計算機に対して割り当て前記ゲストオペレーティングシステムに再度認識させることを特徴とする。
　また、本発明においては、物理ポートを備える一方、前記物理ポートに対応しており設定済みのパラメータ値に従って動作する少なくとも１つの仮想ポートが生成されるＩ／Ｏアダプタと、前記少なくとも１つの仮想ポートに対してアクセスすることによって前記Ｉ／Ｏアダプタを用いて外部とのやり取りを行うゲストオペレーティングシステムが動作する少なくとも１つの仮想計算機と、前記少なくとも１台の仮想計算機及び前記Ｉ／Ｏアダプタを管理する管理用仮想計算機と、前記少なくとも１つの仮想ポートに設定済みのパラメータ値を含むパラメータ情報を不揮発的に保持するハイパバイザと、を備える計算機における再起動方法において、前記管理用仮想計算機が、再起動時に前記ハイパバイザから前記パラメータ情報を取得するパラメータ情報取得ステップと、前記管理用仮想計算機が、前記パラメータ情報に基づく前記パラメータ値を前記少なくとも１つの仮想ポートに再度設定する再設定ステップと、前記管理用仮想計算機が、前記少なくとも１つの仮想ポートを前記少なくとも１台の仮想計算機に対して割り当て前記ゲストオペレーティングシステムに再度認識させる再認識ステップと、を有することを特徴とする。
　本発明によれば、リセット前とリセット後とで同一のパラメータを利用して同一の作動状態で再稼働することができる。
本実施の形態による物理計算機の構成例を示すブロック図である。 本実施の形態による仮想計算機システムの一例を示す機能ブロック図である。 本実施の形態におけるＰＦとＶＦの構成を示すブロック図である。 本実施の形態におけるＰＦとＶＦのバス番号、デバイス番号、ファンクション番号、および、閉塞状態を表す管理情報の一例を示す図である。 ＶＦパラメータ情報の一例を示す図である。 障害発生からＶＦ復旧までの手順の一例を示すシーケンスチャートである。 ハイパバイザによる閉塞処理を示すフローチャートである。 管理用計算機による再起動処理を示すフローチャートである。 管理用計算機によるＶＦパラメータ再設定処理を示すフローチャートである。
　以下、図面について、本発明の一実施の形態について詳述する。
　（１）本実施の形態による仮想計算機システムの構成
　図１は、本実施の形態の物理計算機１０などの構成例を示す。物理計算機１０は、第３のブリッジ８３を介してユーザ端末６００に接続されている。このユーザ端末６００は、詳細な処理は後述するが、物理計算機１０内において第１のＣＰＵ７０－１など並びに第３のブリッジ８３を経由して、第４のＩ／Ｏアダプタ９３を介して物理計算機１０に接続されている。
　物理計算機１０は、複数の中央演算処理装置として第１のＣＰＵ７０－１、第２のＣＰＵ７０－２、・・・、及び第ＮのＣＰＵ７０―Ｎが搭載されている。なお、本実施の形態においてＮは自然数である。第１のＣＰＵ７０－１、第２のＣＰＵ７０－２、・・・、及び第ＮのＣＰＵ７０－Ｎは、ＰＣＩｅｘｐｒｅｓｓ等のバス１１０を介して、メモリ１００の他にも、第１のブリッジ８０及び第２のブリッジ８１に接続されている。
　第１のブリッジ８０は、第１のＩ／Ｏアダプタ９０及び第２のＩ／Ｏアダプタ９１に接続されている。第２のブリッジ８１は第３のＩ／Ｏアダプタ９２に接続されている。
　物理計算機１０上では、１台以上の仮想計算機の一例として第１の仮想計算機３０－１～第Ｎの仮想計算機３０－Ｎと、管理用仮想計算機５０と、この管理用仮想計算機５０を制御するハイパバイザ２０と、が稼働している。
　メモリ１００にはハイパバイザ２０がロードされる。第１の仮想計算機３０－１～第Ｎの仮想計算機３０－Ｎはハイパバイザ２０によって制御されている。第１の仮想計算機３０－１では第１のゲストＯＳ４０－１が実行されており、第Ｎの仮想計算機３０－Ｎでは第２のゲストＯＳ４０－Ｎが実行されている。
　ハイパバイザ２０は、管理用仮想計算機５０において実行される管理用ゲストＯＳ６０を管理する。この管理用ゲストＯＳ６０は、第１の仮想計算機３０－１～第Ｎの仮想計算機３０－Ｎ及び第１のＩ／Ｏアダプタ９０～第３のＩ／Ｏアダプタ９２を管理する。このハイパバイザ２０の詳細については後述する。
　図２は、本実施の形態による仮想計算機システムにおける機能の一例を示す。本実施の形態による仮想計算機システムは、第１のゲストＯＳ４０－１～第ＮのゲストＯＳ４０－Ｎ、第１の仮想計算機３０－１～第Ｎの仮想計算機３０－Ｎ、ハイパバイザ２０、管理用ゲストＯＳ６０、管理用仮想計算機５０、及び第１のＩ／Ｏアダプタ９０、第２のＩ／Ｏアダプタ９１、・・・、第３のＩ／Ｏアダプタ９２を有する。
　第１～第３のＩ／Ｏアダプタ９０～９２は、いわゆるＳＲ－ＩＯＶ機能を搭載している。ＰＦ２００（図示のＰＦ１に相当）からＶＦ２１０，２１１が生成されている。ＰＦ２０１（図示のＰＦ２に相当）からＶＦ２１２，２１３が生成されている。ＰＦ２０２（図示のＰＦ３に相当）からＶＦ２１４，２１５が生成されている。ここでは各ＰＦから２個のＶＦを生成しているが、本実施の形態はＶＦの生成数に関わらず適用することができる。
　管理用仮想計算機５０は、割り当てられたＰＦ２００（図示のＰＦ１に相当）～ＰＦ２０２（図示のＰＦ３に相当）を含む。管理用ゲストＯＳ６０は、ＰＦ２００～ＰＦ２０２の種類に対応するＰＦドライバ２４０を含む。管理用ゲストＯＳ６０のＰＦドライバ２４０は、ＶＦ２１０などを生成する機能を有する。第１の仮想計算機３０－１～第Ｎの仮想計算機３０－Ｎは、割り当てられたＶＦ２１０などを含む。
　第１のゲストＯＳ４０－１～第ＮのゲストＯＳ４０－Ｎは、第１の仮想計算機３０－１～第Ｎの仮想計算機３０－ＮのＶＦ２１０などの種類に対応するＶＦドライバ２５０を含む。仮想計算機のエミュレーションデータ２２０－１～２２０－Ｎは、ＶＦ２１０など、ＰＦ２００などのバス番号、デバイス番号、ファンクション番号及び閉塞状態を表す管理情報を保持する。閉塞とは、障害発生時などに仮想計算機から閉塞されたデバイスへのアクセスを遮断させることをいう。なお、本実施の形態では、主として障害発生時を例示するが、更新時に適用しても良いことは云うまでもない。
　一方、ハイパバイザ２０においては、第１の仮想計算機３０－１～第Ｎの仮想計算機３０－Ｎの第１の仮想計算機エミュレーションデータ２２０－１～第Ｎの仮想計算機のエミュレーションデータ２２０－Ｎ、及び、第１のＶＦパラメータ情報２３０－１～第ＫのＶＦパラメータ情報２３０－Ｋが不揮発的に保持されている。このうち第１の仮想計算機のエミュレーションデータ２２０－１～第Ｎの仮想計算機のエミュレーションデータ２２０－Ｎの詳細については後述する。一方、第１のＶＦパラメータ情報２３０－１～第ＫのＶＦパラメータ情報２３０－Ｋは、各ＶＦ２１０などのパラメータを含んでいる。
　図３は、第１～第３のＩ／Ｏアダプタ９０～９２内のＰＦ及びＶＦの構成例を示すブロック図である。第１のブリッジ８０には、その配下にＰＦ２００及びＰＦ２０１が接続されている。ＰＦ２００からＶＦ２１０（図示の「ＶＦ０」に対応）及びＶＦ２１１（図示の「ＶＦ１」に対応）が生成されている。ＶＦ２０１からＶＦ２１２（図示の「ＶＦ０」に対応）及びＶＦ２１３（図示の「ＶＦ１」に対応）が生成されている。
　一方、第２のブリッジ８１にはその配下にＰＦ２０２が接続されている。このＰＦ２０２からＶＦ２１４（図示の「ＶＦ０」に対応）及びＶＦ２１５（図示の「ＶＦ１」に対応）が生成されている。
　ＰＦ２００，２０１，２０２の閉塞時には、当該閉塞するＰＦの配下にあるＶＦも含めて閉塞する。例えば、第１のＩ／Ｏアダプタ９０のＰＦ２００で障害が発生してＰＦ２００を閉塞する場合、このＰＦ２００の配下にあるＶＦ２１０，２１１も同時に閉塞される。本実施の形態では、ＰＦ配下のデバイスを閉塞しているが、ブリッジ配下を閉塞したりＶＦ単体を閉塞するようにしても良い。
　図４は、図３に示す構成においてハイパバイザ２０によって作成される仮想計算機のエミュレーションデータ２２０－１～２２０－Ｎの一例を示す。なお、エミュレーションデータ２２０－１～２２０－Ｎは大きなリストの一部であり、バスを指定して閉塞対象を指定可能となっている。これら仮想計算機のエミュレーションデータ２２０－１～２２０－Ｎは、ハイパバイザ２０によって保有されているデバイスの管理情報を示している。各行は、各デバイスの管理情報に対応している。
　デバイス種４００は、各デバイスの種別を表している。Ｂｕｓ＃４１０、Ｄｅｖ＃４２０及びＦｕｎｃ＃４３０は、ＰＣＩ仕様で策定されている、合計１６Ｂｉｔのシステム内でユニークな値であり、物理計算機１０内でデバイスを一意に特定するために用いる。
　ＰＦ＃４４０は、デバイスが所属するＰＦ番号である。デバイス種４００が「ＰＦ」である場合は自身のＰＦ番号を保持する一方、デバイス種４００が「ＶＦ」である場合は生成元ＰＦ番号を保持する。
　ＶＦ＃４５０は、生成元ＰＦ内におけるＶＦの通し番号を示している。デバイス種４００が「ＰＦ」である場合はＶＦ＃４５０を持たない。
　閉塞状態＃４６０は、デバイスが閉塞しているか否かを表す管理情報である。既述のように閉塞とは、仮想計算機からデバイスへのアクセスを遮断させることである。例えば、デバイスに障害が発生した際など、障害が発生しているデバイスを使用し続けることで異なる障害を誘発する可能性があるため、デバイスを閉塞させる。
　図５は、ＶＦパラメータ情報２３０－１～２３０－Ｋの構成例である。ＬＰＡＲ＃５００は、ＶＦが割り当てられている仮想計算機の番号を示している。ＰＦＢｕｓ＃５１０、ＰＦＤｅｖ＃５２０及びＰＦＦｕｎｃ＃５３０は、ＶＦの生成元ＰＦのＢｕｓ番号、Ｄｅｖｉｃｅ番号及びＦｕｎｃｔｉｏｎ番号を示している。
　ハイパバイザ２０は、ＰＦＢｕｓ＃５１０、ＰＦＤｅｖ＃５２０、ＰＦＦｕｎｃ＃５３０及びＶＦ＃４５０の組み合わせを用いてＶＦを一意に特定できる。ＭＡＣアドレス５４０、ＶＬＡＮ　ＩＤ５５０、及びＴｘＲａｔｅ５６０は、各ＶＦが個別に持つパラメータである。ハイパバイザ２０は、ＶＦパラメータ情報２３０－１～２３０－Ｋを利用して全てのＶＦ分のパラメータを管理している。
　（２）仮想計算機システムの再起動方法
　図６は、本実施の形態における障害発生からＶＦ復旧までの流れを示したシーケンスチャートである。ステップＳ６１１～ステップＳ６１５が稼働時抜去（ＨｏｔＲｅｍｏｖｅ）に該当し、ステップＳ６２５が稼働時取り付け（ＨｏｔＡｄｄ）に該当する。
　なお、ステップＳ６１０における障害通知は、本実施の形態では管理用ゲストＯＳ６０からハイパバイザ２０に対して障害通知を行ったが、障害原因によってハイパバイザ２０自身が障害を検出したことを契機に復旧処理を行う場合がある。また、障害発生時に限らずドライバ等のオンラインアップデートによるＰＦ、ＶＦの復旧にも本実施の形態を同様に利用できる。ドライバ更新時は、ドライバの再初期化が必要となるため、障害時と同様に一度デバイスを閉塞させ、再認識させるという処理が必要になる。
　まず、ステップＳ６１０では、管理用ゲストＯＳ６０がハイパバイザ２０に対して障害通知を行う。ステップＳ６１１では、障害通知を受けたハイパバイザ２０は閉塞処理に移行する。ステップＳ６１２では、ハイパバイザ２０が管理用ゲストＯＳ６０に対してＰＦ閉塞処理要求を送出する。ステップＳ６１３では、ハイパバイザ２０が第１のゲストＯＳ４０－１～第ＮのゲストＯＳ４０－Ｎに対してそれぞれＶＦ閉塞処理要求を送出する。
　ステップＳ６１４では、第１のゲストＯＳ４０－１～第ＮのゲストＯＳ４０－Ｎが仮想計算機のエミュレーションデータ２２０－１～２２０－Ｎ（図２参照）において管理されている閉塞状態４６０を閉塞状態に変更する。ステップＳ６１５では、ハイパバイザ２０が第１のゲストＯＳ４０－１～第ＮのゲストＯＳ４０－Ｎに対してデバイス再認識処理要求を送出し、第１のゲストＯＳ４０－１～第ＮのゲストＯＳ４０－Ｎが自身の認識しているデバイスを再サーチすることによりＶＦ２１０（図示のＶＦ１０に相当）の認識が解除される。
　ステップＳ６１６では、ハイパバイザ２０がＶＦ２１０に対して終了処理を行うことにより、ＶＦ２１０がリセットされる。次にステップＳ６１７では、ハイパバイザ２０が、ＰＦ２００が管理用ゲストＯＳ６０から解除されるまで待った後に終了処理を行うことにより、ＰＦ２００がリセットされる。ステップＳ６１８では、ハイパバイザ２０が、ユーザ端末６００に対し、デバイスが閉塞したことを通知する。
　ユーザ端末６００は、任意のタイミングで、復旧処理の要求をハイパバイザ２０に対して指示する（ステップＳ６１９）。ハイパバイザ２０は、この復旧処理の要求に応じて、管理用仮想計算機５０の管理用ゲストＯＳ６０に対して再起動命令を送出する（ステップＳ６２０）。
　次にステップＳ６２１では、管理用仮想計算機５０において管理用ゲストＯＳ６０が再起動された後、ＰＦドライバ２４０のロードを開始する。その後、ＳＲ－ＩＯＶ機能が有効であるか否かが判定される。ステップＳ６２２では、管理用ゲストＯＳ６０が、ＰＦドライバ２４０のロード中に第１～第３のＩ／Ｏアダプタ９０，９１，９２の設定を確認し、いわゆるＳＲ－ＩＯＶ対応Ｉ／Ｏアダプタである場合、即ち、ＳＲ－ＩＯＶ機能が有効である場合には有効化オプションを用いてＰＦドライバの組み込みが行われる。これにより、ＰＦドライバをロードして、実際にＶＦを生成する。一方、ＳＲ－ＩＯＶ機能が有効でない場合には有効化オプションを用いずにＰＦドライバのみ組み込みが行われる。
　ステップＳ６２３では、ハイパバイザ２０が、管理用ゲストＯＳ６０に対して、それぞれのＶＦ２１０などについてパラメータ値を設定すべき旨のＶＦ設定要求を送出する。管理用ゲストＯＳ６０は、このＶＦ設定要求の受け取りを契機としてハイパバイザ２０からＶＦパラメータ情報２３０－１～２３０－Ｋを取得し、それぞれのＶＦ２１０などに対して各種パラメータを設定する（ステップＳ６２４）。
　ハイパバイザ２０は、第１のゲストＯＳ４０－１～第ＮのゲストＯＳ４０－Ｎに対してデバイス再認識処理要求を送出することにより、第１のゲストＯＳ４０－１～第ＮのゲストＯＳ４０－ＮがＶＦ２１０を再認識してＶＦ２１０などが復旧する（ステップＳ６２５）。ＶＦ２１０などは上記各種パラメータ値を用いて動作することができるようになる。
　以上のシーケンスについてより詳しくフローチャートを用いて説明する。図７は、図６に示したステップＳ６１１～ステップＳ６１７において実行される閉塞処理の一例を示す。
　ステップＳ７００では、障害が発生したＰＦ、ＶＦが所属するＰＦ配下の全ＶＦに対してオフライン要求が送出される。このオフライン要求は、ゲストＯＳ４０－１からのアクセスを停止するための要求である。
　このようなオフライン要求がなされると、その後、第１のゲストＯＳ４０－１～第ＮのゲストＯＳ４０－Ｎのいずれかからアクセスがあった場合でも、ハイパバイザ２０は、デバイスに応答を返さない。即ち、ハイパバイザ２０は当該アクセスを受けないように制御する。
　ハイパバイザ２０が所定の割り込みを第１のゲストＯＳ４０－１～第ＮのゲストＯＳ４０－ＮのいずれかのゲストＯＳに対して与えると、その後このゲストＯＳが自らが使用できるデバイスを検索した際に、上記停止したデバイスを認識することができなくなり、当該デバイスはアクセスに対する応答を返さないようになる（ＨｏｔＰｌｕｇの処理）。このような処理は起動時に行っても良い。
　ステップＳ７０１では、ハイパバイザ２０が、図４に示すエミュレーションデータ２２０－１～２２０－Ｎにおいて閉塞対象のＰＦ及びＶＦの閉塞状態４６０を「閉塞」に設定する。このように閉塞状態４６０が「閉塞」に設定されると、ハイパバイザ２０は、第１のゲストＯＳ４０－１～第ＮのゲストＯＳ４０－ＮによるＰＣＩＣｏｎｆｉｇアクセスに対して応答不能である旨を返す。これにより、第１のゲストＯＳ４０－１～第ＮのゲストＯＳ４０－Ｎは、それぞれ、既述のデバイス再認識処理ステップＳ６１５において、当該デバイスが消失していることを認識できる状態になる。
　ステップＳ７０２では、ハイパバイザ２０が、ゲストＯＳ４０－１に対してデバイス再認識処理要求を送出し、ゲストＯＳ４０－１が論理デバイスを再サーチすることで、ＶＦ２１０の認識が解除される。ステップＳ７０３では、ハイパバイザ２０がステップＳ７００において送出したオフライン要求に対する処理が完了するまで待ち状態となる。
　ステップＳ７０４では、ハイパバイザ２０が閉塞対象となるブリッジ配下の全ＶＦに対して終了処理を要求し、これによりＶＦ２１０などがリセットされる。終了処理では、ＤＭＡ転送停止、割り込み停止、ＥｒｒｏｒＲｅｐｏｒｔの抑止が行われることによりデバイスを停止する。
　ステップＳ７０５では、ハイパバイザ２０が、閉塞対象となるブリッジ配下の全ＰＦに対して終了処理を要求し、これによりＰＦ２００などがリセットされる。終了処理の動作は既述のステップＳ７０４と同様である。
　図８は、図６に示したステップＳ６１９～ステップＳ６２２で行うＶＦ生成処理のフローチャートである。ステップＳ８００では、ハイパバイザ２０が管理用ゲストＯＳ６０に対して、再起動命令を発行する。
　ステップＳ８０１では、管理用ゲストＯＳ６０が再起動される。ステップＳ８０２では、ハイパバイザ２０が、管理用ゲストＯＳ６０を再起動する際、第１～第３のＩ／Ｏアダプタ９０，９１，９２においてＳＲ－ＩＯＶが有効な設定となっているか否か判定する。
　ステップＳ８０３では、ステップＳ８０２において第１～第３のＩ／Ｏアダプタ９０，９１，９２においてＳＲ－ＩＯＶが有効なＩ／Ｏアダプタであると判定された場合、ハイパバイザ２０が、ＳＲ－ＩＯＶ有効化オプションを用いてＰＦドライバ２４０を組込み、ＶＦ２１０などを生成する。なお、ステップＳ８０３は、デバイスの種類によって処理が異なり、ＰＦドライバのロードが完了した後に設定を行うことでＶＦを生成する場合がある。
　ステップＳ８０４では、ステップＳ８０２においてＳＲ－ＩＯＶ有効でないと判定された場合、ハイパバイザ２０が、ＳＲ－ＩＯＶ有効化オプションを用いずにＰＦドライバ２４０を組み込む。
　図９は、図６に示したステップＳ６１８～ステップＳ６２４において実行するＶＦ再設定処理の一例を示す。ステップＳ９００では、管理用ゲストＯＳ６０が、ＶＦパラメータ情報２３０－１などをハイパバイザ２０から取得する。ステップＳ９０１では、管理用ゲストＯＳ６０がＰＦドライバ２４０を用いてＶＦパラメータの設定を行う。
　ステップＳ９０２では、管理用ゲストＯＳ６０がステップＳ９０１におけるＶＦパラメータの設定に関してタイムアウトが発生したか否かを判定する。タイムアウトが発生しなかった場合、管理用ゲストＯＳ６０がＶＦパラメータ結果確認処理を行う。一方、タイムアウトが発生した場合は、管理用ゲストＯＳ６０が、ＶＦパラメータの設定に失敗したと判定し、ハイパバイザ２０に対して当該設定が失敗した旨を通知する。
　ステップＳ９０３では、管理用ゲストＯＳ６０がＶＦパラメータ情報２３０－１とＶＦ２１０との設定同士を比較し、パラメータに誤りが無ければハイパバイザ２０に対して設定完了を通知する。
　ステップＳ９０４では、管理用ゲストＯＳ６０がハイパバイザ２０に対して、ＶＦパラメータ設定の結果を通知する。さらに管理用ゲストＯＳ６０は、第１のゲストＯＳ４０－１に対してデバイスの再確認処理を実施する。これにより、ゲストＯＳ４０－１がデバイスを認識することができるようになっている。このため、ゲストＯＳ４０－１は各ＶＦを認識することができるようになり使用することができる。
　（３）本実施の形態の効果等
　以上説明したように、上記実施の形態における計算機１０では、管理用仮想計算機５０が、再起動時にハイパバイザ２０から取得したパラメータ情報に基づくパラメータ値を少なくとも１つの仮想ポート２１０，２１１に再度設定し、当該少なくとも１つの仮想ポート２１０，２１１を少なくとも１台の仮想計算機３０－１～３０－Ｎに対して割り当てゲストオペレーティングシステム４０－１～４０－Ｎに再度認識させるている。
　このような構成によれば、リセット前とリセット後とで、同一のＶＦパラメータの値を利用して仮想ポートを使用することができるようにし、同一の作動状態で動作させることができる。
　（４）その他の実施形態
　上記実施形態は、本発明を説明するための例示であり、本発明をこれらの実施形態にのみ限定する趣旨ではない。本発明は、その趣旨を逸脱しない限り、様々な形態で実施することができる。例えば、上記実施形態では、各種プログラムの処理をシーケンシャルに説明したが、特にこれにこだわるものではない。従って、処理結果に矛盾が生じない限り、処理の順序を入れ替え又は並行動作するように構成しても良い。
　本発明は、仮想ポートを利用する仮想計算機を有する計算機及び計算機の再起動方法に広く適用することができる。
　１０……物理計算機、２０……ハイパバイザ、３０－１～３０－N……仮想計算機、４０－１～４０－N……第１～第NのゲストＯＳ、５０……管理用仮想計算機、６０……管理用ゲストＯＳ、７０……ＣＰＵ、８０……ブリッジ、９０……Ｉ／Ｏアダプタ、１００……バス、２００……ＰＦ、２１０……ＶＦ、２２０－１～２２０－Ｎ……仮想計算機のエミュレーションデータ、２３０－１～２３０－Ｋ……ＶＦパラメータ情報、２４０……ＰＦドライバ、２５０……ＶＦドライバ。

Claims (10)

  1. 　物理ポートを備える一方、前記物理ポートに対応しており設定済みのパラメータ値に従って動作する少なくとも１つの仮想ポートが生成されるＩ／Ｏアダプタと、
    　前記少なくとも１つの仮想ポートに対してアクセスすることによって前記Ｉ／Ｏアダプタを用いて外部とのやり取りを行うゲストオペレーティングシステムが動作する少なくとも１つの仮想計算機と、
    　前記少なくとも１台の仮想計算機及び前記Ｉ／Ｏアダプタを管理する管理用仮想計算機と、
    　前記少なくとも１つの仮想ポートに設定済みのパラメータ値を含むパラメータ情報を不揮発的に保持するハイパバイザと、
    　を備え、
    　前記管理用仮想計算機は、
    　再起動時に前記ハイパバイザから取得した前記パラメータ情報に基づく前記パラメータ値を前記少なくとも１つの仮想ポートに再度設定し、前記少なくとも１つの仮想ポートを前記少なくとも１台の仮想計算機に対して割り当て前記ゲストオペレーティングシステムに再度認識させる
    　ことを特徴とする計算機。
  2. 　前記ハイパバイザは、
    　前記Ｉ／Ｏアダプタにおける前記物理ポートと前記少なくと１つの仮想ポートとの対応関係及び閉塞されているか否かの状態を管理するエミュレーションデータを保持していることを特徴とする請求項１に記載の計算機。
  3. 　前記管理用仮想計算機は、
    　前記パラメータ情報に基づく前記パラメータ値を前記少なくとも１つの仮想ポートに再度設定した後、前記ハイパバイザに対して結果の通知を実施することを特徴とする請求項１に記載の計算機。
  4. 　前記管理用仮想計算機は、
    　管理用ゲストオペレーティングシステムと、
    　前記物理ポートに対応した前記少なくとも１つの仮想ポートを生成する物理ポートドライバと、を有し、
    　前記ハイパバイザは、
    　外部から復旧要求を受け取ると、前記管理用ゲストオペレーティングシステムに対して再起動命令を行うことにより、前記管理用ゲストオペレーティングシステムに前記物理ポートドライバに対して前記少なくとも１つの仮想ポートを生成させることを特徴とする請求項３に記載の計算機。
  5. 　前記ハイパバイザは、
    　前記前記管理用ゲストオペレーティングシステムに対して前記少なくとも１つの仮想ポートについて前記パラメータ値を設定すべき旨の要求を行い、前記管理用ゲストオペレーティングシステムに前記パラメータ情報を提供して前記物理ポートドライバに前記少なくとも１つの仮想ポートについて前記パラメータ情報に基づく前記パラメータ値を再設定させることを特徴とする請求項４に記載の計算機。
  6. 　物理ポートを備える一方、前記物理ポートに対応しており設定済みのパラメータ値に従って動作する少なくとも１つの仮想ポートが生成されるＩ／Ｏアダプタと、
    　前記少なくとも１つの仮想ポートに対してアクセスすることによって前記Ｉ／Ｏアダプタを用いて外部とのやり取りを行うゲストオペレーティングシステムが動作する少なくとも１つの仮想計算機と、
    　前記少なくとも１台の仮想計算機及び前記Ｉ／Ｏアダプタを管理する管理用仮想計算機と、
    　前記少なくとも１つの仮想ポートに設定済みのパラメータ値を含むパラメータ情報を不揮発的に保持するハイパバイザと、
    　を備える計算機における再起動方法において、
    　前記管理用仮想計算機が、再起動時に前記ハイパバイザから前記パラメータ情報を取得するパラメータ情報取得ステップと、
    　前記管理用仮想計算機が、前記パラメータ情報に基づく前記パラメータ値を前記少なくとも１つの仮想ポートに再度設定する再設定ステップと、
    　前記管理用仮想計算機が、前記少なくとも１つの仮想ポートを前記少なくとも１台の仮想計算機に対して割り当て前記ゲストオペレーティングシステムに再度認識させる再認識ステップと、
    　を有することを特徴とする計算機の再起動方法。
  7. 　前記ハイパバイザは、
    　前記Ｉ／Ｏアダプタにおける前記物理ポートと前記少なくと１つの仮想ポートとの対応関係及び閉塞されているか否かの状態を管理するエミュレーションデータを保持していることを特徴とする請求項６に記載の計算機の再起動方法。
  8. 　前記管理用仮想計算機は、
    　前記再設定ステップを実行した後、前記ハイパバイザに対して結果の通知を実施することを特徴とする請求項６に記載の計算機の再起動方法。
  9. 　前記管理用仮想計算機は、
    　管理用ゲストオペレーティングシステムと、
    　前記物理ポートに対応した前記少なくとも１つの仮想ポートを生成する物理ポートドライバと、を有し、
    　前記ハイパバイザは、
    　外部から復旧要求を受け取ると、前記管理用ゲストオペレーティングシステムに対して再起動命令を行うことにより、前記管理用ゲストオペレーティングシステムに前記物理ポートドライバに対して前記少なくとも１つの仮想ポートを生成させることを特徴とする請求項８に記載の計算機の再起動方法。
  10. 　前記ハイパバイザは、前記再設定ステップにおいて、
    　前記前記管理用ゲストオペレーティングシステムに対して前記少なくとも１つの仮想ポートについて前記パラメータ値を設定すべき旨の要求を行い、前記管理用ゲストオペレーティングシステムに前記パラメータ情報を提供して前記物理ポートドライバに前記少なくとも１つの仮想ポートについて前記パラメータ情報に基づく前記パラメータ値を再設定させることを特徴とする請求項９に記載の計算機の再起動方法。
PCT/JP2016/084370 2016-11-18 2016-11-18 計算機及び計算機の再起動方法 WO2018092287A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2016/084370 WO2018092287A1 (ja) 2016-11-18 2016-11-18 計算機及び計算機の再起動方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2016/084370 WO2018092287A1 (ja) 2016-11-18 2016-11-18 計算機及び計算機の再起動方法

Publications (1)

Publication Number Publication Date
WO2018092287A1 true WO2018092287A1 (ja) 2018-05-24

Family

ID=62145348

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/084370 WO2018092287A1 (ja) 2016-11-18 2016-11-18 計算機及び計算機の再起動方法

Country Status (1)

Country Link
WO (1) WO2018092287A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006085543A (ja) * 2004-09-17 2006-03-30 Hitachi Ltd 仮想計算機システム
JP2012203636A (ja) * 2011-03-25 2012-10-22 Hitachi Ltd 仮想計算機の制御方法及び計算機
JP2013120552A (ja) * 2011-12-08 2013-06-17 Hitachi Ltd 仮想計算機システム、仮想計算機管理プログラム、及びｍａｃアドレス管理方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006085543A (ja) * 2004-09-17 2006-03-30 Hitachi Ltd 仮想計算機システム
JP2012203636A (ja) * 2011-03-25 2012-10-22 Hitachi Ltd 仮想計算機の制御方法及び計算機
JP2013120552A (ja) * 2011-12-08 2013-06-17 Hitachi Ltd 仮想計算機システム、仮想計算機管理プログラム、及びｍａｃアドレス管理方法

Similar Documents

Publication Publication Date Title
US8954963B2 (en) Method and apparatus for resetting a physical I/O adapter without stopping a guest OS running on a virtual machine
US10333865B2 (en) Transformation of peripheral component interconnect express compliant virtual devices in a network environment
US8386654B2 (en) System and method for transforming PCIe SR-IOV functions to appear as legacy functions
US11106622B2 (en) Firmware update architecture with OS-BIOS communication
US9262363B2 (en) PCI and PCI express virtual hot plug systems and methods
JP6029550B2 (ja) 計算機の制御方法及び計算機
TWI684864B (zh) 管理輸入輸出可虛擬化儲存裝置中之功能級重置
US9684530B2 (en) System and method for assigning virtual functions and management host thereof
WO2017209854A1 (en) Hot-plug hardware and software implementation
US8271707B2 (en) Method and system for PCI hybrid function
JP5667552B2 (ja) 仮想計算機システム、仮想計算機管理プログラム、及びｍａｃアドレス管理方法
WO2017006458A1 (ja) 計算機及びメモリ領域管理方法
CN109656675B (zh) 总线设备、计算机设备及实现物理主机云存储的方法
US11144326B2 (en) System and method of initiating multiple adaptors in parallel
US9304779B2 (en) Optimizing boot time of a storage system
JP5876149B2 (ja) サーバー・コンピュータを開始させるためのコンピュータ・システム、方法、サーバー・コンピュータ、管理ステーションおよび使用
WO2018092287A1 (ja) 計算機及び計算機の再起動方法
CN113467850A (zh) 管理程序移除
US10509746B2 (en) Information processing apparatus, storage medium and information processing method
JP6745405B2 (ja) ストレージシステム及びマッピング方法
JP5998482B2 (ja) 監視システム
JP6682897B2 (ja) 通信設定方法、通信設定プログラム、情報処理装置および情報処理システム
US20120284711A1 (en) Method and Arrangement for Configuring a Resource for a Virtual Runtime Environment
US11822948B2 (en) Peripheral component interconnect (PCI) device removal for virtual machines
WO2021181537A1 (ja) 情報処理装置、情報処理方法および情報処理プログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16921624

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16921624

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP