Abstract:
It is provided a computer system comprising a plurality of computers; a PCI switch; and a plurality of I/O devices connected to the PCI switch, wherein the communication path includes a virtual switch and virtual bridges, and the PCI switch comprises a communication path generating module for setting the virtual switches and the virtual bridges, a virtual switch group management module for creating a virtual switch group including the at least one of the virtual switches, and setting an enabled flag to one of the virtual switches included in the virtual switch group, and a port management module for managing relation between each of the generated communication paths and the plurality of ports included in the each of the generated communication paths.

Description:
CLAIM OF PRIORITY 
       [0001]    The present application claims priority from Japanese patent application JP 2009-134682 filed on Jun. 4, 2009, the content of which is hereby incorporated by reference into this application. 
       CROSS REFERENCE TO RELATED APPLICATIONS 
       [0002]    This application claims the benefit of the following applications filed in the United States Patent and Trademark Office, U.S. patent application Ser. No. 12/546,264 entitled “COMPUTER SYSTEM AND METHOD FOR SHARING PCI DEVICES THEREOF”, filed on Aug. 24, 2009, and U.S. patent application Ser. No. 12/709,405 entitled “COMPUTER SYSTEM, METHOD OF MANAGING PCI SWITCH, AND MANAGEMENT SERVER”, filed on Feb. 19, 2010, the disclosures of all of which are herein incorporated by reference in their entireties. 
       BACKGROUND OF THE INVENTION 
       [0003]    This invention relates to a multi-computer system in which a plurality of computers and a plurality of PCI devices are connected by a PCI switch, and more particularly, to enhancing the reliability of a multi-root PCI switch. 
         [0004]    In recent years, blade servers which house a plurality of computers in a single machine have been put into use in order to facilitate server management. Further, improvement in processing performance of CPUs brought about by a multi-core technology, which gives a CPU a plurality of processor cores, has led to widespread use of a virtual server technology, which uses a CPU efficiently by running a plurality of virtual servers on a single computer. 
         [0005]    While the CPU performance has improved, there has been a shortage of I/O devices which require connectors and ports for input and output. In order to remedy the shortage of I/O devices, there is known a method of enhancing the extensibility and flexibility of I/O devices with the use of a PCI switch technology. 
         [0006]    In order to enhance the reliability of this type of server system where components are connected via a PCI switch, the system needs to be built in a manner that prevents a failure in a single device or server from affecting the entire system (in a manner that avoids single point of failure (SPOF)), which includes preparing redundant paths and setting up failover to a backup system. 
         [0007]    For instance, there is a method in which two PCI switches are connected to each other, which normally allow the switches&#39; respective hosts to access assigned devices, and in the event of a host failure, the connection is switched to cascade connection to allow one of the hosts to access all devices as described in, for example, US 2008/0240134 A1. With this method, however, dealing with a failure requires the re-assigning of bus numbers and similar procedures that make it difficult to execute failover while the devices are running. 
         [0008]    Non-transparent bridging may be used in configuring a PCI switch that connects a plurality of hosts as described in, for example, an article by Jack Regula titled “Using Non-transparent Bridging in PCI Express Systems,” June 2004, pp. 24-27. A non-transparent bridge is a bridge that combines two PCI-PCI bridges to connect two PCI bus trees to each other. This bridge is recognized by each host as an end point, and when a memory is accessed via a base address register (BAR), the address is converted to forward the access to the other PCI bus tree. With this method, however, switching hosts is inevitably accompanied by resetting and re-initialization. 
         [0009]    The PCI-SIG, which is the PCI Special Interest Group, defines a multi-root I/O virtualization (MR-IOV) standards, which extend a PCI switch used by a conventional single server such that a plurality of computers are connected to a plurality of peripheral component interconnect (PCI) devices (or PCIe(xpress) devices) which are I/O devices as described in, for example, an online document “Multi-Root I/O Virtualization and Sharing Specification Rev1.0” published by PCI-SIG in May 2008, pp 109-222. 
         [0010]    A device compliant with the MR-IOV standards (MR device) has a plurality of virtual hierarchy (VH) layers each of which is allocated to a virtual switch configured from a switch compliant with the MR-IOV standards (MR switch). A single MR device is thus shared by a plurality of server hosts and used concurrently by the server hosts. 
         [0011]    According to the MR-IOV standards, management software called a PCI manager is used to manage the configuration information of MR switches and MR devices. The PCI manager itself uses a management virtual switch called VH0 (management virtual switch VH0) for settings in the MR switches and the MR devices. 
         [0012]    Every MR switch and every MR device that are managed by the PCI manager are connected to the management virtual switch VH0, and the virtual hierarchy layer VH0 in the MR device holds a special function for management (base function: BF). A host that includes the management virtual switch VH0 (hereinafter, may also be referred to as manager host) can therefore present a single point of failure. 
         [0013]    When a failure occurs in the manager host, the BF of an MR device that is managed by the manager host is reset. Resetting the BF deletes configuration information in which the MR device is partitioned on a VH basis and accordingly affects all hosts that have been sharing and using this MR device. Also in the case where the shutting down of the manager host is scheduled for planned maintenance or firmware update and the configuration information is migrated to another host, the manager host cannot be shut down without affecting hosts that are using an MR device managed by the manager host. 
       SUMMARY OF THE INVENTION 
       [0014]    The MR-IOV standards do not define failover of the management virtual switch VH0 as described above. Switching between virtual switches in accordance with the MR-IOV standards is accomplished by such methods as (1) dynamically changing a port connection between virtual switches and (2) changing a virtual switch connection through hot-plug. 
         [0015]    However, in both the methods (1) and (2) described above, there is a period in which virtual switches (virtual bridges that constitute the virtual switches) and ports are disconnected from each other, and the instant the disconnection occurs, the event is regarded as a linkdown and the BF of every relevant MR device is reset. The goal of “switching the management virtual switch VH0 without affecting other hosts that are using the MR device” is therefore not achieved with the methods (1) and (2). 
         [0016]    A representative aspect of this invention is as follows. That is, there is provided a computer system, comprising: a plurality of computers each comprising a processor, a memory connected to the processor, and an interface connected to the processor; a PCI switch which is connected to each of the plurality of computers via the interface; and a plurality of I/O devices which are connected to the PCI switch. The PCI switch comprises: a plurality of ports to which one of the plurality of computers and the plurality of I/O devices are connected; and a switch management module for setting a communication path for connecting one of the plurality of computers and one of the plurality of I/O devices. The communication path includes at least one of virtual switches and a plurality of virtual bridges, the at least one of virtual switches constituting paths including the communication paths which connect the one of the plurality of virtual bridges to each other, each of the plurality of virtual bridges connecting the one of the virtual switches and one of the plurality of ports. The switch management module comprises: a communication path generating module for setting the plurality of virtual switches and the plurality of virtual bridges to generate at least one of the communication paths from the set one of the virtual switches and from the set one of the plurality of virtual bridges; a virtual switch group management module for creating a virtual switch group including the at least one of the plurality of virtual switches, and setting an enabled flag to one of the plurality of virtual switches included in the virtual switch group to indicate that connection with one of the plurality of ports is enabled; and a port management module for managing relation between each of the generated communication paths and at least one of the plurality of ports included in the each of the generated communication paths based on settings of the communication path generating module and settings of the virtual switch group management module. 
         [0017]    The multiple virtual switches are provided, and switching between the virtual switches can be made without resetting any relevant I/O device, which prevents an active computer from presenting the single point of failure. A computer system that is highly reliable overall can thus be built. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0018]    The present invention can be appreciated by the description which follows in conjunction with the following figures, wherein: 
           [0019]      FIG. 1  is a block diagram illustrating an example of a configuration of a computer system according to a first embodiment of this invention; 
           [0020]      FIG. 2  is a block diagram illustrating the internal configuration of the host computers according to the first embodiment of this invention; 
           [0021]      FIG. 3  is an explanatory diagram illustrating a virtual hierarchy within the MR devices according to the first embodiment of this invention; 
           [0022]      FIG. 4  is a diagram illustrating function types according to the first embodiment of this invention; 
           [0023]      FIG. 5  is an explanatory diagram illustrating the configuration of a virtual switch that has the host computer X at the top according to the first embodiment of this invention; 
           [0024]      FIG. 6  is an explanatory diagram illustrating the configuration of a virtual switch that has the host computer Z at the top according to the first embodiment of this invention; 
           [0025]      FIG. 7  is an explanatory diagram illustrating the configuration of a virtual switch that has the host W at the top according to the first embodiment of this invention; 
           [0026]      FIG. 8  is an explanatory diagram illustrating the configuration of the virtual switch that has the host Y at the top according to the first embodiment of this invention; 
           [0027]      FIG. 9  is an explanatory diagram illustrating an association relation between the virtual switch management table and the virtual bridge management table according to the first embodiment of this invention; 
           [0028]      FIG. 10  is an explanatory diagram illustrating the configuration of the virtual switch that has the host X at the top after the takeover according to the first embodiment of this invention; 
           [0029]      FIG. 11  is an explanatory diagram illustrating the configuration of the virtual switch that has the host Y at the top after the takeover according to the first embodiment of this invention; 
           [0030]      FIG. 12  is an explanatory diagram illustrating an association relation among the virtual switch management table, the virtual bridge management table, and the virtual switch group management table according to the first embodiment of this invention; 
           [0031]      FIG. 13  is an explanatory diagram illustrating an association relation among the virtual switch management table, the virtual bridge management table, and the virtual switch group management table according to the first embodiment of this invention; 
           [0032]      FIG. 14  is a block diagram illustrating the configuration of the virtual switch generating logic that is included in the multi-root PCI switch according to the first embodiment of this invention; 
           [0033]      FIG. 15  is an explanatory diagram illustrating an example of processing that the port mapping information generating module executes according to the first embodiment of this invention; 
           [0034]      FIGS. 16 and 17  are explanatory diagrams illustrating the PCI bus tree management table according to the first embodiment of this invention; 
           [0035]      FIGS. 18 and 19  are explanatory diagrams illustrating a user-operated interface for manipulating the host-device allocation table by calling up the PCI manager through the management console according to the first embodiment of this invention; 
           [0036]      FIG. 20  is a flow chart illustrating processing of planned takeover according to the first embodiment of this invention; 
           [0037]      FIG. 21  is a flow chart illustrating processing of takeover upon failure according to the modification example of the first embodiment of this invention; 
           [0038]      FIG. 22  is an explanatory diagram illustrating a virtual switch group management table according to a second embodiment of this invention; 
           [0039]      FIG. 23  is an explanatory diagram illustrating an example of the failure settings according to the second embodiment of this invention; 
           [0040]      FIG. 24  is a flow chart illustrating processing that is executed when the multi-root PCI switch switches the virtual switches upon detection of a failure in the host X according to the second embodiment of this invention; 
           [0041]      FIG. 25  is a flow chart illustrating processing that is executed by the active host X according to the second embodiment of this invention; 
           [0042]      FIG. 26  is a flow chart illustrating processing that is executed by the backup host Y according to the second embodiment of this invention; 
           [0043]      FIG. 27  is an explanatory diagram illustrating an example of the topology information according to the first embodiment of this invention; and 
           [0044]      FIG. 28  is a flow chart illustrating processing that the port mapping information generating module executes according to the first embodiment of this invention. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0045]    Embodiments of this invention are described below with reference to the accompanying drawings. 
       First Embodiment 
       [0046]      FIG. 1  is a block diagram illustrating an example of a configuration of a computer system according to a first embodiment of this invention. 
         [0047]    The computer system includes hosts  100   a  to  100   d , multi-root I/O devices (hereinafter, also referred to as MR devices)  300   a  to  300   d , which are used by the hosts  100   a  to  100   d , and a multi-root PCI switch  200 , which connects the hosts  100   a  to  100   d  and the MR devices  300   a  to  300   d  to each other. 
         [0048]    When there is no particular need to distinguish one from another, the hosts  100   a  to  100   d  are each referred to as host  100  and the MR devices  300   a  to  300   d  are each referred to as MR device  300 . 
         [0049]    A PCI manager  290  which manages the multi-root PCI switch  200  and the MR devices  300  is run on the host  100   a.    
         [0050]    The hosts  100   a  to  100   d  are connected to one another via a management network  270 . A management console  280  is connected to the management network  270 , enabling an administrator to manage the PCI manager  290  through the management console  280 . 
         [0051]    The multi-root PCI switch  200  includes four upstream ports  210   a  to  210   d  and four downstream ports  220   a  to  220   d . When there is no particular need to distinguish one from another in the following description, the upstream ports  210   a  to  210   d  are each referred to as upstream port  210  and the downstream ports  220   a  to  220   d  are each referred to as downstream port  220 . 
         [0052]    The upstream ports  210   a  to  210   d  are connected to the hosts  100   a  to  100   d , respectively. Specifically, the upstream ports  210   a  to  210   d  are connected to root ports  110   a  to  110   d  of the hosts  100   a  to  100   d , respectively. The downstream ports  220   a  to  220   d  are connected to the MR devices  300   a  to  300   d , respectively. 
         [0053]    The multi-root PCI switch  200  includes a virtual switch generating logic  260  and a routing control module  250 . 
         [0054]    The virtual switch generating logic  260  determines settings relevant to virtual switches  400  illustrated in  FIG. 5  and generates the virtual switches  400 . Details of the virtual switch generating logic  260  are described later with reference to  FIG. 14 . 
         [0055]    The routing control module  250  routes packets input from the ports  210  and  220  in accordance with settings determined by the virtual switch generating logic  260 , specifically, port mapping information  263  and virtual switch configuration information  264  which are input from the virtual switch generating logic  260 . 
         [0056]    The routing control module  250  is connected to the upstream ports  210   a  to  210   d  and to the downstream ports  220   a  to  220   d  via internal buses  230   a  to  230   h , respectively. The virtual switch generating logic  260  is connected to the upstream ports  210   a  to  210   d  via switch management paths  240   a  to  240   d , respectively. 
         [0057]      FIG. 2  is a block diagram illustrating the internal configuration of the hosts  100   a  to  100   d  according to the first embodiment of this invention. While  FIG. 2  illustrates the internal configuration of the host  100   a , the other hosts  100   b  to  100   d  have the same configuration as that of the host  100   a.    
         [0058]    The host  100   a  includes a CPU  120 , which performs computing, a memory  130 , an I/O hub  140 , and a storage  150 . The CPU  120  executes a program deployed in the memory  130 . 
         [0059]    The CPU  120  and the memory  130  are connected to each other via a memory bus  146 . The CPU  120  and the I/O hub  140  are connected to each other via an internal bus  145 . The host  100   a  may alternatively be configured such that the I/O hub  140  is replaced by a chipset with a built-in memory controller, and the memory bus  146  is connected to the chipset. The following description applies to either configuration. 
         [0060]    The I/O hub  140  includes a root port  110   a , which is connected to the multi-root PCI switch  200  via an I/O bus  111 . 
         [0061]    The host  100   a  has one I/O hub  140  and one root port  110   a  in the example of  FIG. 2  for simpler illustration, but may have a plurality of I/O hubs  140  and a plurality of root ports  110   a.    
         [0062]    The I/O hub  140  is connected to the storage  150  via a storage I/F  147 . The storage  150  is a medium that stores non-volatile information, such as a hard disk drive or a non-volatile memory. 
         [0063]    The storage  150  stores an OS and other components necessary for boot-up, a PCI manager program  151 , and management setting values  152 . 
         [0064]    The memory  130  after boot-up is partitioned into a memory code section  131  and a memory data section  132 . 
         [0065]    The PCI manager program  151  is deployed in the memory  130  as a PCI manager executing code  133 , and executed by the CPU  120 . An MR device driver  134  is deployed in the memory  130  and executed by the CPU  120  when the MR device driver  134  needs to be executed in order to enable the multi-root PCI switch  200  to execute processing unique to the respective MR devices  300 . 
         [0066]    The memory code section  131  may store a failover monitoring module  137 . The failover monitoring module  137  monitors the host  100   a  for a failure and, in the event of a failure, executes failover to one of the other hosts  100   b  to  100   d . Details of the processing executed by the failover monitoring module  137  are described later with reference to  FIG. 21 . 
         [0067]    The memory data section  132  stores a PCI bus tree management table  136 , a virtual switch group management table  510 , a virtual switch management table  520 , a virtual bridge management table  530 , a host-device allocation table  650 , and topology information  660 . 
         [0068]    The PCI bus tree management table  136  is described later with reference to  FIGS. 16 and 17 . 
         [0069]    The virtual switch group management table  510 , the virtual switch management table  520 , and the virtual bridge management table  530  are respective copies of the virtual switch group management table  510 , the virtual switch management table  520 , and the virtual bridge management table  530  that the virtual switch generating logic  260  stores. The virtual switch group management table  510 , the virtual switch management table  520 , and the virtual bridge management table  530  are described later with reference to  FIGS. 12 and 13 . 
         [0070]    The host-device allocation table  650  is described later with reference to  FIGS. 18 and 19 . The topology information  660  is described later with reference to  FIG. 27 . 
         [0071]    The host  100   a  is connected to the management network  270  via a network controller  160 . 
         [0072]    (Virtual Hierarchy of MR Devices and Virtual Switch Configuration) 
         [0073]      FIG. 3  is an explanatory diagram illustrating a virtual hierarchy within the MR devices  300  according to the first embodiment of this invention, illustrating an example of virtual hierarchy layer allocation to the hosts  100 . 
         [0074]    The internal resource of each MR device  300  is divided by a unit called a virtual hierarchy layer  310 . One virtual hierarchy layer  310  is distinguished from another by virtual hierarchy number (VHN). 
         [0075]    A single virtual hierarchy layer holds one or more functions. The virtual hierarchy layers  310  of each MR device  300  are individually connected to the virtual switches  400  shown in  FIG. 6 , thereby enabling the plurality of hosts  100   a  to  100   d  to access the same MR device out of the MR devices  300   a  to  300   d  concurrently. 
         [0076]    Function types are now described. 
         [0077]      FIG. 4  is a diagram illustrating function types according to the first embodiment of this invention. 
         [0078]    The base function (BF) is a special function used by the PCI manager  290  and is located only on a virtual hierarchy layer that has a virtual hierarchy number “VH0”. Other virtual hierarchy layers  310  than VH0 normally hold one or more physical functions (PFs) and a plurality of virtual functions (VFs). 
         [0079]    In the example of  FIG. 3 , the virtual hierarchy layers VH0 of the MR devices  300   a  to  300   d  are allocated to a host X ( 100   a ), VH1 of the MR device  300   a  and VH1 of the MR device  300   b  are allocated to a host Z ( 100   c ), and VH2 of the MR device  300   b , VH1 of the MR device  300   c , and VH1 of the MR device  300   d  are allocated to a host W ( 100   d ). 
         [0080]      FIGS. 5 to 7  illustrate an example of what configurations the virtual switches  400  and the virtual bridges  410  in the multi-root PCI switch  200  have when the virtual hierarchy layers are allocated as described above. The virtual bridges  410  include upstream virtual bridges and downstream virtual bridges. 
         [0081]    Each virtual switch  400  is made up of one upstream virtual bridge  410  and zero or more downstream virtual bridges  410 . The upstream virtual bridge  410  is connected to one of the upstream ports  210   a  to  210   d . The downstream virtual bridges  410  are connected to one of the virtual hierarchy layers  310  (VHNs) at the downstream ports  220   a  to  220   d . The downstream virtual bridges  410  do not always need to be connected to the downstream ports  220   a  to  220   d.    
         [0082]      FIG. 5  is an explanatory diagram illustrating the configuration of a virtual switch  400 - 0  that has the host X ( 100   a ) at the top according to the first embodiment of this invention. 
         [0083]    In the example of  FIG. 5 , a virtual hierarchy layer of the upstream port  210   a  whose VHN is 0 and an upstream virtual bridge  410 - 0  are connected to each other. Under the upstream virtual bridge  410 - 0 , four downstream virtual bridges  410 - 1  to  410 - 4  are connected. The downstream virtual bridges  410 - 1  to  410 - 4  are respectively connected to virtual hierarchy layers “VHN=0” of the downstream ports  220   a  to  220   d , and connected to the virtual hierarchy layers  310  (VHN=0) of the MR devices  300   a  to  300   d  via the downstream ports  220   a  to  220   d.    
         [0084]      FIG. 6  is an explanatory diagram illustrating the configuration of a virtual switch  400 - 2  that has the host Z ( 100   c ) at the top according to the first embodiment of this invention. 
         [0085]    In the example of  FIG. 6 , a virtual hierarchy layer “VHN=0” of the upstream port  210   c  and an upstream virtual bridge  410 - 10  are connected to each other. Under the upstream virtual bridge  410 - 10 , two downstream virtual bridges  410 - 11  and  410 - 12  are connected. The downstream virtual bridge  410 - 11  is connected to a virtual hierarchy layer “VHN=1” of the downstream port  220   a , and the downstream virtual bridge  410 - 12  is connected to a virtual hierarchy layer “VHN=1” of the downstream port  220   b . The downstream virtual bridges  410 - 11  and  410 - 12  are connected to the virtual hierarchy layers  310  of the MR devices  300   a  and  300   b  via the downstream ports  220   a  and  220   b.    
         [0086]      FIG. 7  is an explanatory diagram illustrating the configuration of a virtual switch  400 - 3  that has the host W ( 100   d ) at the top according to the first embodiment of this invention. 
         [0087]    In the example of  FIG. 7 , a virtual hierarchy layer “VHN=0” of the upstream port  210   d  and an upstream virtual bridge  410 - 15  are connected to each other. Under the upstream virtual bridge  410 - 15 , three downstream virtual bridges  410 - 16  to  410 - 18  are connected. The downstream virtual bridge  410 - 16  is connected to a virtual hierarchy layer “VHN=2” of the downstream port  220   b , the downstream virtual bridge  410 - 17  is connected to a virtual hierarchy layer “VHN=1” of the downstream port  220   c , and the downstream virtual bridge  410 - 18  is connected to a virtual hierarchy layer “VHN=1” of the downstream port  220   d . The downstream virtual bridges  410 - 16  to  410 - 18  are connected to the virtual hierarchy layers  310  of the MR devices  300   b  to  300   d  via the downstream ports  220   b  to  220   d.    
         [0088]    (Eliminating Single Point of Failure (SPOF), and Failover) 
         [0089]    In the configurations of  FIGS. 5 to 7 , the host Z ( 100   c ) and the host W ( 100   d ) share the same MR device,  300   b . However, connected to different virtual hierarchy layers  310 , the host Z ( 100   c ) and the host W ( 100   d ) can use fragments of the divided resource of the MR device  300   b  separately from each other. 
         [0090]    For example, in the case where a failure occurs in the host Z ( 100   c ), the influence of the failure is contained within the virtual hierarchy layer of the MR device  300   b  whose VHN is 1, and accordingly does not affect the host W ( 100   d ), which uses the virtual hierarchy layer “VHN=2” of the MR device  300   b.    
         [0091]    An exception to this is a failure in the virtual hierarchy layer “VHN=0” of the host X ( 100   a ). The virtual hierarchy layers “VHN=0” of the MR devices  300   a  to  300   d  hold a base function for setting the division of the MR devices  300   a  to  300   d  into virtual hierarchy layers. 
         [0092]    Therefore, when a failure occurs in the host X ( 100   a ) or when the host X ( 100   a ) is rebooted, the virtual hierarchy layers “VHN=0” of the MR devices  300   a  to  300   d  under management of the host X ( 100   a ) are reset. Then, the base function is reset, deleting other virtual hierarchy layers (VHN≧1) and affecting the host Z ( 100   c ) and the host W ( 100   d ) as well. In short, the host X ( 100   a ) which serves as a manager host presents a single point of failure in the configurations of  FIGS. 5 to 7 . 
         [0093]    A possible way to avoid single point of failure is to prepare a backup host Y ( 100   b ) illustrated in  FIG. 8  so that the host Y ( 100   b ) can take over from the host X ( 100   a ) (failover). The configuration of a virtual switch  400 - 1  that is topped by the host Y ( 100   b ) prior to the failover is illustrated in  FIG. 8 . 
         [0094]      FIG. 8  is an explanatory diagram illustrating the configuration of the virtual switch  400 - 1  hat has the host Y ( 100   b ) at the top according to the first embodiment of this invention t. 
         [0095]    In the example of  FIG. 8 , a virtual hierarchy layer “VHN=0” of the upstream port  210   b  and an upstream virtual bridge  410 - 5  are connected to each other. Under the upstream virtual bridge  410 - 5 , four downstream virtual bridges  410 - 6  to  410 - 9  are connected. The downstream virtual bridges  410 - 6  to  410 - 9  are not connected to the downstream ports  220   a  to  220   d.    
         [0096]    In MR-IOV specifications, an arbitrary combination of a port and a virtual hierarchy layer “VHN” cannot be connected to two or more virtual bridges  410  concurrently. This is because connecting two or more virtual bridges  410  simultaneously to the same downstream port  220  creates a plurality of roots for the port, which is not acceptable in a proper PCI bus tree and does not guarantee correct operation. 
         [0097]    This is why the downstream virtual bridges  410 - 6  to  410 - 9  and the downstream ports  220   a  to  220   d  are not connected to each other in the example of  FIG. 8 , where the virtual hierarchy layers “VHN=0” of the downstream ports  220   a  to  220   d  are connected to the downstream virtual bridges  410 - 1  to  410 - 4  under the virtual switch  400 - 0  of the host X ( 100   a ). 
         [0098]    A description is given on the virtual switch management table  520  and the virtual bridge management table  530  that are set in the virtual switch generating logic  260  of the multi-root PCI switch  200  before this invention is applied. 
         [0099]    In the following description, the host X ( 100   a ) is also referred to as manager host X ( 100   a ) and the host Y ( 100   b ) is also referred to as backup host Y ( 100   b ). 
         [0100]      FIG. 9  is an explanatory diagram illustrating an association relation between the virtual switch management table  520  and the virtual bridge management table  530  according to the first embodiment of this invention. 
         [0101]    The virtual switch management table  520  and virtual bridge management table  530  of  FIG. 9  are a simplified version of tables prescribed in the MR-IOV specifications but essentially the same as the tables prescribed in the MR-IOV specifications. 
         [0102]    Each entry in the virtual switch management table  520  includes a virtual switch number  521 , an enabled flag  522 , a start virtual bridge number  523 , and a virtual bridge entry count  524 . The start virtual bridge number  523  and the virtual bridge entry count  524  serve as a pointer to an entry of the virtual bridge management table  530 . 
         [0103]    Each entry in the virtual bridge management table  530  includes a virtual bridge number  531 , an enabled flag  532 , a direction flag  533 , which indicates upstream or downstream, a port mapping state  534 , which indicates whether to map the virtual bridge in question onto a port, a port number  535  of the mapping destination port, and a virtual hierarchy number (VHN)  536  of a mapping destination virtual hierarchy layer. 
         [0104]    The virtual switch management table  520  and virtual bridge management table  530  of  FIG. 9  reflect the configurations of  FIGS. 5 to 8 . 
         [0105]    Discussed below is a case in which the backup host Y ( 100   b ) takes over the virtual hierarchy layers “VHN=0” of the MR devices ( 300   a  to  300   d ) from the manager host X ( 100   a ) (failover/takeover from the host X ( 100   a ) to the host Y ( 100   b )). Configuration diagrams of the virtual switches after the takeover are illustrated in  FIGS. 10 and 11 . 
         [0106]      FIG. 10  is an explanatory diagram illustrating the configuration of the virtual switch  400 - 0  that has the host X ( 100   a ) at the top after the takeover according to the first embodiment of this invention.  FIG. 11  is an explanatory diagram illustrating the configuration of the virtual switch  400 - 1  that has the host Y ( 100   b ) at the top after the takeover according to the first embodiment of this invention. 
         [0107]    The downstream virtual bridges  410 - 1  to  410 - 4  of the virtual switch  400 - 0  topped by the manager host X ( 100   a ) are no longer mapped onto the downstream ports  220   a  to  220   d  and, instead, the downstream virtual bridges  410 - 6  to  410 - 9  of the virtual switch  400 - 1  topped by the backup host Y ( 100   b ) are now mapped onto the downstream ports  220   a  to  220   d.    
         [0108]    In order to overwrite the virtual switch management table  520  and virtual bridge management table  530  of  FIG. 9  such that the configurations of  FIGS. 10 and 11  are reflected, the port mapping state  534  needs to be changed in a plurality of entries of the virtual bridge management table  530 . 
         [0109]    Specifically, in every entry that has one of “1” to “4” as the VB #  531 , the port mapping state  534  needs to be changed from “Yes” to “No” whereas the port mapping state  534  needs to be changed from “No” to “Yes” in every entry that has one of “6” to “9” as the VB #  531 . 
         [0110]    Those changes, which cannot be executed concurrently, are executed sequentially. In executing the changes sequentially, avoiding connecting two or more virtual bridges  410  to the same port simultaneously in accordance with the MR-IOV specifications inevitably creates a temporary period in which the downstream ports  220   a  to  220   d  are not connected to any of the virtual bridges  410 . In the MR-IOV specifications, the port  220  that is connected to no virtual bridge  410  is regarded as a linkdown and is immediately reset. 
         [0111]    The goal of taking over from the manager host X ( 100   a ) without resetting the base function therefore cannot be achieved with the takeover method in which entries of the virtual bridge management table  530  are overwritten sequentially. 
         [0112]    This invention achieves failover of the manager host X ( 100   a ) without resetting the base function of any relevant MR device and without deviating from the PCI/MR-IOV specifications by adding a function of switching the connection state of the virtual switches  400  concurrently to the multi-root PCI switch  200 . 
         [0113]    For that purpose, a plurality of virtual switches  400  are grouped and a pointer that points to one enabled virtual switch  400  among a group of virtual switches  400  is prepared. The mapping of other virtual switches  400  in the group than the pointed virtual switch  400  to the downstream ports  220  is disabled. 
         [0114]    When the pointer is changed to point to another virtual switch  400 , the mapping of the virtual switch  400  that has been enabled onto one of the downstream ports  220  is disabled and, instead, the mapping of the newly pointed virtual switch  400  onto one of the downstream ports  220  is enabled. 
         [0115]    The changes in mapping state are executed concurrently with the change of the pointer as a trigger. Creating a state that deviates from the PCI/MR-IOV specifications (state in which a virtual hierarchy layer “VHN” of one port is mapped onto two or more virtual bridges  410 ) is thus avoided. In addition, because every port is connected to one or another of the virtual switches  400  all the time, resetting accompanying a linkdown is prevented. 
         [0116]    Details of this function are described below. 
         [0117]      FIG. 12  is an explanatory diagram illustrating an association relation among the virtual switch management table  520 , the virtual bridge management table  530 , and the virtual switch group management table  510  according to the first embodiment of this invention. 
         [0118]      FIG. 12  shows settings prior to take over from the manager host X ( 100   a ). The multi-root PCI switch  200  of this invention includes the virtual switch group management table  510  in addition to the virtual switch management table  520  and the virtual bridge management table  530  which are prescribed in the MR-IOV specifications. 
         [0119]    Each entry in the virtual switch group management table  510  includes a virtual switch group number (VS Grp #)  511 , an enabled flag  512 , a virtual switch list (VS list)  513 , and an enabled virtual switch number (enabled VS #)  514 . The virtual switch group number  511  is an identifier for identifying a group that consists of a plurality of virtual switches  400  (virtual switch group). 
         [0120]    In the example of  FIG. 12 , a virtual switch group that has “0” as the virtual switch group number  511  is enabled. The virtual switch group having “0” as the virtual switch group number  511  contains the virtual switch  400  that has “0” as the VS # (virtual switch number)  521  and the virtual switch  400  that has “1” as the VS #  521 . Of the two virtual switches  400 , one that has “0” as the VS #  521  is designated as the enabled virtual switch  400 . 
         [0121]    In accordance with the settings of the virtual switch group management table  510 , the virtual switch  400  that has “0” as the VS #  521  is enabled in the virtual switch management table  520  and, in the virtual bridge management table  530 , every virtual bridge  410  that has one of “0” to “4” as the VB #  531  is enabled and mapped onto one of the downstream ports  220 . 
         [0122]    On the other hand, the virtual switch  400  belonging to the same virtual switch group that has “1” as the VS #  521  is disabled and the mapping of the downstream virtual bridges  410  of this virtual switch  400  onto the downstream ports  220  is accordingly disabled in the virtual switch group management table  510 . A state in which two or more virtual bridges  410  are connected to one downstream port  220  can thus be avoided. 
         [0123]    In the example of  FIG. 12 , the port mapping state  534  is “Yes” for both the virtual switch  400  that has “0” as the VS #  521  and the virtual switch  400  that has “1” as the VS #  521 , which means that those virtual switches  400  are connectable virtual switches. Connecting the virtual bridges  410  and the downstream ports ( 220   a  to  220   d ) is actually implemented by the routing control module  250 . 
         [0124]    Specifically, based on the port mapping information  263  and the virtual switch configuration information  264  which are input from the virtual switch generating logic  260 , the routing control module  250  enables the connection (mapping) between the virtual bridge  410  that has “0” as the VB #  531  and one of the downstream ports ( 220   a  to  220   d ), and disables the connection (mapping) between the virtual bridge  410  of the virtual switch  400  that has “1” as the VS #  521  and one of the downstream ports ( 220   a  to  220   d ). 
         [0125]      FIG. 13  is an explanatory diagram illustrating an association relation among the virtual switch management table  520 , the virtual bridge management table  530 , and the virtual switch group management table  510  according to the first embodiment of this invention.  FIG. 13  shows a state after the backup host Y ( 100   b ) takes over from the manager host X ( 100   a ). 
         [0126]      FIG. 13  differs from  FIG. 12  in that the enabled virtual switch number  514  is changed from “0” to “1” in an entry of the virtual switch group management table  510  that has “0” as the virtual switch group number  511 . 
         [0127]    Through this change, the mapping of the downstream virtual bridges  410  onto the downstream ports  220  is disabled in the virtual switch  400  having “0” as the VS #  521  which has been enabled, whereas the mapping of the downstream virtual bridges  410  onto the downstream ports  220  is enabled in the virtual switch  400  belonging to the same virtual switch group that has “1” as the VS #  521 . 
         [0128]    This switching takes place concurrently at all ports under the virtual switches  400  that are switched. Therefore, duplicated connection in which more than one virtual bridge  410  is connected to a single port  220  can be avoided, as well as a state in which the virtual bridges  410  are disconnected from the ports  220 . Takeover from the manager host X ( 100   a ) to the backup host Y ( 100   b ) can thus be executed without allowing the base function of any relevant MR device to be reset. 
         [0129]    (Configuration of the Virtual Switch Generating Logic) 
         [0130]      FIG. 14  is a block diagram illustrating the configuration of the virtual switch generating logic  260  that is included in the multi-root PCI switch  200  according to the first embodiment of this invention. 
         [0131]    The virtual switch generating logic  260  includes the virtual switch group management table  510 , the virtual switch management table  520 , the virtual bridge management table  530 , a port mapping information generating module  261 , and a virtual switch configuration information generating module  262 . 
         [0132]    The port mapping information generating module  261  generates the port mapping information  263  based on information that is input from the virtual switch group management table  510  and from the virtual switch management table  520 , and outputs the generated port mapping information  263  to the routing control module  250 . 
         [0133]    The virtual switch configuration information generating module  262  generates the virtual switch configuration information  264  based on information that is input from the virtual switch management table  520  and from the virtual bridge management table  530 , and outputs the generated virtual switch configuration information  264  to the routing control module  250 . 
         [0134]    The PCI manager  290  sets the virtual switch group management table  510 , the virtual switch management table  520 , and the virtual bridge management table  530  separately via the switch management paths  240 . 
         [0135]    The set information is output to the routing control module  250  through the port mapping information generating module  261  and the virtual switch configuration information generating module  262  as the port mapping information  263  and the virtual switch configuration information  264 . The routing control module  250  uses the input port mapping information  263  and virtual switch configuration information  264  to grasp the connection relation between ports, and to route packets that travel along the internal buses  230 . 
         [0136]    A change from  FIG. 12  to  FIG. 13  is accomplished by the port mapping information generating module  261 . Processing executed by the port mapping information generating module  261  is described below. 
         [0137]      FIG. 15  is an explanatory diagram illustrating an example of processing that the port mapping information generating module  261  executes according to the first embodiment of this invention. 
         [0138]    The port mapping information generating module  261  refers to the virtual switch group management table  510  and the virtual switch management table  520  to extract, from an entry of a virtual switch group that is enabled, virtual switch numbers listed on the virtual switch list  513 . 
         [0139]    For each of the extracted virtual switch numbers, the port mapping information generating module  261  identifies a virtual switch that is assigned the virtual switch number, and chooses the VB numbers  531  of the virtual bridges  410  of this virtual switch that are mapped onto an arbitrary downstream port  220  (here, the arbitrary downstream port is  220   a  and the virtual bridges that have “1” and “6” as their respective VB numbers  531  are chosen). 
         [0140]    Of the chosen virtual bridges  410 , the port mapping information generating module  261  enables only the mapping of the virtual bridge  410  belonging to a virtual switch that is indicated by the enabled virtual switch number  514 , and disables the mapping of all other chosen virtual bridges  410 . 
         [0141]    The port mapping information generating module  261  executes the processing of  FIG. 15  for all the downstream ports  220  (here,  220   a  to  220   d ). 
         [0142]    The port mapping information generating module  261  outputs port mapping information of the downstream ports  220  chosen through the processing of  FIG. 15 , together with port mapping information of the upstream ports  210 , as the port mapping information  263 . 
         [0143]      FIG. 28  is a flow chart illustrating processing that the port mapping information generating module  261  executes according to the first embodiment of this invention.  FIG. 28  is a representation of the processing of  FIG. 15  in the form of flow chart. 
         [0144]    The port mapping information generating module  261  initializes the port mapping information  263  (Step  1600 ). 
         [0145]    The port mapping information generating module  261  refers to the virtual switch management table  520  to execute processing for every virtual switch number  521  (Step  1610 ). Specifically, the port mapping information generating module  261  processes each virtual switch number  521  separately. 
         [0146]    The port mapping information generating module  261  determines whether or not the chosen virtual switch number  521  is found on the virtual switch list  513  in an arbitrary entry of the virtual switch group management table  510  (Step  1620 ). 
         [0147]    Determining that the chosen virtual switch number  521  is not on the virtual switch list  513  in an arbitrary entry of the virtual switch group management table  510 , the port mapping information generating module  261  proceeds to Step  1650 . 
         [0148]    Determining that the chosen virtual switch number  521  is on the virtual switch list  513  in an arbitrary entry of the virtual switch group management table  510 , the port mapping information generating module  261  determines whether or not the enabled flag  512  of the entry is “Yes” (Step  1630 ). 
         [0149]    Determining that the enabled flag  512  of the entry is not “Yes”, the port mapping information generating module  261  proceeds to Step  1650 . 
         [0150]    Determining that the enabled flag  512  of the entry is “Yes”, the port mapping information generating module  261  determines whether or not the chosen virtual switch number  521  matches the enabled virtual switch number  514  (Step  1640 ). 
         [0151]    Determining that the chosen virtual switch number  521  matches the enabled virtual switch number  514 , the port mapping information generating module  261  refers to the virtual bridge management table  530  to extract any entry for the virtual bridge  410  under the virtual switch  400  that is identified by the chosen virtual switch number  521  where the enabled flag  532  is “Yes” and the port mapping state  534  is “Yes”, and adds every extracted entry to the port mapping information  263  (Step  1650 ). 
         [0152]    Determining that the chosen virtual switch number  521  does not match the enabled virtual switch number  514 , the port mapping information generating module  261  refers to the virtual bridge management table  530  to extract only an entry for the virtual bridge  410  under the virtual switch  400  that is identified by the chosen virtual switch number  521  where the enabled flag  532  is “Yes”, the port mapping state  534  is “Yes”, and the direction flag  533  is “up”, and adds the extracted entry to the port mapping information  263  (Step  1660 ). 
         [0153]    Through Step  1660 , the mapping of the virtual bridge  410  onto the upstream port  210  is enabled whereas the mapping of the virtual bridges  410  onto the downstream ports  220  is disabled. 
         [0154]    The port mapping information generating module  261  executes loop processing (Step  1620  to Step  1660 ) until every virtual switch number  521  in the virtual switch management table  520  is processed (Step  1670 ). 
         [0155]    The port mapping information generating module  261  outputs results of Step  1620  to Step  1660  to the routing control module  250  as the port mapping information  263  (Step  1680 ), and then ends the processing. 
         [0156]    (Failover Processing within the PCI Manager) 
         [0157]    Next, failover processing within the PCI manager  290  is described. 
         [0158]      FIG. 16  is an explanatory diagram illustrating the PCI bus tree management table  136  according to the first embodiment of this invention.  FIG. 16  shows a PCI bus tree management table  136 - x , which is held in the PCI manager  290  on the host X ( 100   a ) prior to take over (failover). 
         [0159]    Devices and bridges along PCI buses are each uniquely identified by an identifier that is a combination of a bus #  601 , a device #  602 , and a func. #  603 , and managed by the identifier. 
         [0160]    As a device type  604 , information indicating whether a device in question is a root complex, a bridge, or one of the MR devices  300  is stored. A device name is stored as a device name  605  in the case where the device type  604  is the MR device  300 . 
         [0161]    When the device in question is accessible through memory-mapped I/O, a base address  606  and a size  607  are stored as well. 
         [0162]    In the example of  FIG. 16 , a device that has “0” as the bus #  601  corresponds to a root complex (in this case, corresponds to the I/O hub  140 ). A device that has “1” as the bus #  601  corresponds to the upstream virtual bridge  410 - 0 . Devices that have “2” as the bus #  601  and “0” to “3” as the device #  602  correspond to the downstream virtual bridges  410 - 1  to  410 - 4 , respectively. A device that has “3” as the bus #  601 , a device that has “4” as the bus #  601 , a device that has “5” as the bus #  601 , and a device that has “6” as the bus #  601  correspond to an MR device A ( 300   a ), an MR device B ( 300   b ), an MR device C ( 300   c ), and an MR device D ( 300   d ), respectively. 
         [0163]      FIG. 17  is an explanatory diagram illustrating the PCI bus tree management table  136  according to the first embodiment of this invention.  FIG. 17  shows a PCI bus tree management table  136 - y , which is held in the PCI manager  290  on the host Y ( 100   b ) prior to take hover (failover). 
         [0164]    In the virtual switch  400 - 1  which is used by the host Y ( 100   b ), the tree leads to the virtual bridges  410  but does not reach the MR devices  300  because those virtual bridges  410  are not connected to the downstream ports  220  at the time. Accordingly, if the procedures of usual PCI bus enumeration are followed, a PCI bus tree that contains no device is created. 
         [0165]    The host Y ( 100   b ) avoids this by communicating with the active host X ( 100   a ) over the management network  270 , or via a register inside the multi-root PCI switch  200 , to prepare for takeover (failover). 
         [0166]    The host Y ( 100   b ) makes preparation by creating the PCI bus tree management table  136 - y  based on the PCI bus tree management table  136 - x  of the host X ( 100   a ). 
         [0167]    Specifically, the host Y ( 100   b ) prepares backup device entries for devices that the host Y is to take over (in this example, the device A ( 300   a ) to the device D ( 300   d )) in entries of the PCI bus tree management table  136 - y  that correspond to entries of the PCI bus tree management table  136 - x  where a value “device” is stored as the device type  604  (in this example, entries having “3” to “6” as the bus #  601 ). In the backup device entries, the bus #  601 , device #  602 , func. #  603 , base address  606 , and size  607  of the devices that the host Y ( 100   b ) is to take over are reserved. 
         [0168]    In this manner, the host Y ( 100   b ) can take over the MR devices  300  that are under the host X ( 100   a ) without needing to re-enumerate PCI buses or to re-assign memory-mapped I/O addresses. 
         [0169]    (Procedures of Planned Failover) 
         [0170]      FIGS. 18 and 19  are explanatory diagrams illustrating a user-operated interface for manipulating the host-device allocation table  650  by calling up the PCI manager  290  through the management console  280  according to the first embodiment of this invention. 
         [0171]    Each entry in the host-device allocation table  650  includes a manager host specifying field (manager host)  651 , a host name (host)  652 , a device specifying field (device)  653 , and a virtual hierarchy number specifying field (VHN)  654 . 
         [0172]    The manager host specifying field  651  holds information indicating whether the manager host X ( 100   a ) is an active host or a backup host. As the host name  652 , a host name (or a host number) is stored. The device specifying field  653  holds the MR devices  300  to which the manager host X ( 100   a ) is connected. The virtual hierarchy number specifying field  654  holds virtual hierarchy layer numbers of the MR devices  300 . 
         [0173]    The user-operated interface for manipulating the host-device allocation table  650  may, if necessary, be a graphical user interface that displays the state of the virtual switches  400  as those illustrated in  FIGS. 5 to 8 , instead of the text-based screen of  FIG. 18 . 
         [0174]    The PCI manager  290  creates the virtual switch group management table  510 , the virtual switch management table  520 , and the virtual bridge management table  530  based on the host-device allocation table  650  and the topology information  660 , which shows for each of the ports  210  and ports  220  of the multi-root PCI switch  200  what is connected to the port. The PCI manager  290  manages the virtual switches  400  based on the created management tables. 
         [0175]    Specifically, the PCI manager  290  inputs the created management tables to the virtual switch generating logic  260  within the multi-root PCI switch  200  to execute the generation and management of the virtual switches  400 . 
         [0176]    The topology information  660  is now described. 
         [0177]      FIG. 27  is an explanatory diagram illustrating an example of the topology information  660  according to the first embodiment of this invention. 
         [0178]    The topology information  660  includes a port number  661 , a direction  662 , a component type  663 , a device name  664 , and a maximum virtual hierarchy layer count (max VH count)  665 . 
         [0179]    As the port number  661 , an identifier for identifying each of the ports  210  and the ports  220  in the multi-root PCI switch  200  is stored. As the direction  662 , there is stored information that indicates whether a port identified by the port number  661  is one of the upstream ports  210  or one of the downstream ports  220 . 
         [0180]    As the component type  663 , there is stored a type of a device that is connected to the port identified by the port number  661 . As the device name  664 , there is stored an identifier by which one of the MR devices  300  is identified when the component type  663  is “MR device”. As the maximum virtual hierarchy layer count  665 , there is stored a count of virtual hierarchy layers that can be created in the MR device  300 . 
         [0181]    A description is given below on procedures that an administrator follows via the screen of the management console  280  to switch the manager host from the host X ( 100   a ) to the host Y ( 100   b ) in accordance with a plan. 
         [0182]    The administrator manipulates the host-device allocation table  650  such that an attribute in the manager host specifying field  651  for the host Y ( 100   b ) is switched from “backup” to “active” as shown in  FIG. 19 . Because the host Y ( 100   b ) and the host X ( 100   a ) belong to the same virtual switch group, an attribute in the manager host specifying field  651  for the host X ( 100   a ) is switched from “active” to “backup” in conjunction with this switching manipulation by the administrator. After that, a prompt for confirming the switching is displayed on the screen of the management console  280  and, upon approval by the administrator, planned takeover is started. 
         [0183]      FIG. 20  is a flow chart illustrating processing of planned takeover according to the first embodiment of this invention. 
         [0184]    Upon reception of a request to start planned takeover from the administrator (Step  1000 ), the active host X ( 100   a ) suspends MMIO access to devices under its management and also stops issuing an interrupt to the PCI manager  290  (Step  1010 ). An interrupt to the PCI manager  290  is made with the use of, for example, message signaled interrupt (MSI) or INTx #. 
         [0185]    The active host X ( 100   a ) waits until all MMIO requests and DMA requests that have been issued are fulfilled (Step  1020 ). After the MMIO requests and DMA requests that have been issued are all fulfilled, it is guaranteed that the virtual switches  400  of the active host X ( 100   a ) do not contain any in-flight transactions (Txs). 
         [0186]    The active host X ( 100   a ) then overwrites the enabled virtual switch number  514  of the virtual switch group management table  510  (Step  1030 ). In this embodiment, the enabled virtual switch number  514  is changed from “0” to “1”. 
         [0187]    The active host X ( 100   a ) hands information over to the backup host Y ( 100   b ) (Step  1040 ). With the handing over of information, actual devices shown in the PCI bus tree management table  136 - x  of  FIG. 16  replace values in the “backup device” entries of the PCI bus tree management table  136 - y  of the backup host Y ( 100   b ). 
         [0188]    The backup host Y ( 100   b ) lifts the suspension of an interrupt to the PCI manager  290  and the suspension of MMIO request issuance (Step  1050 ). 
         [0189]    From then on, the backup host Y ( 100   b ) manages the devices, including the PCI manager  290 , as an active host Y ( 100   b ) (Step  1060 ). 
         [0190]    The first embodiment of this invention has now been described. 
       Modification Example of the First Embodiment 
     Takeover Upon Failure (=Failover) 
       [0191]    A modification example of the first embodiment of this invention is described next. 
         [0192]    A difference between this modification example and the first embodiment is when to execute failover to the backup host Y ( 100   b ). Specifically, in the modification example of the first embodiment, the backup host Y ( 100   b ) detects a failure in the active host X ( 100   a ) and the detection of the failure triggers the execution of failover. 
         [0193]    A computer system in the modification example and its components including the hosts  100  and the multi-root PCI switch  200  have the same configurations as those in first embodiment. Descriptions on the components are therefore omitted here, and the focus is placed on differences from the first embodiment in the following description. 
         [0194]      FIG. 21  is a flow chart illustrating processing of takeover upon failure according to the modification example of the first embodiment of this invention. 
         [0195]    The active host X ( 100   a ) and the backup host Y ( 100   b ) monitor each other through their failover monitoring modules  137  with the use of heartbeat or the like (Step  1100 ). A network for heartbeat may be prepared separately from the management network  270 . 
         [0196]    While monitoring the active host X ( 100   a ), the backup host Y ( 100   b ) copies information of the active host X ( 100   a ) at suitable intervals to synchronize with the active host X ( 100   a ) (Step  1110 ). The backup host Y ( 100   b ) needs to copy information of the active host X ( 100   a ) only once in the case where there are no changes in the state of the MR devices  300  and other components. The backup host Y ( 100   b ) may also copy information of the active host X ( 100   a ) after a change is detected in the state of the MR devices  300  or other components. 
         [0197]    The backup host Y ( 100   b ) uses the failover monitoring module  137  to determine whether or not a failure has occurred in the active host X ( 100   a ) (Step  1120 ). The backup host Y ( 100   b ) repeats Step  1100  to Step  1120  until a failure in the active host X ( 100   a ) is detected. 
         [0198]    Detecting a failure in the active host X ( 100   a ), the backup host Y ( 100   b ) overwrites the enabled virtual switch number  514  in the virtual switch group management table  510  with one of the virtual switches  400  to which the backup host Y ( 100   b ) belongs (Step  1130 ). In this example, the enabled virtual switch number  514  is changed from “0” to “1”. 
         [0199]    This processing allows the backup host Y ( 100   b ) to take over from the active host X ( 100   a ). However, because there may be an in-flight Tx unlike the planned takeover, the backup host Y ( 100   b ) executes processing of restoring the Tx. 
         [0200]    There is also a possibility that an interrupt is lost, and the backup host Y ( 100   b ) accordingly executes the restoration of the interrupt state of devices that are placed under the backup host Y ( 100   b ) (Step  1140 ). Specifically, the backup host Y ( 100   b ) refers to an interrupt bit of an interrupt register (not shown) to identify the cause of the interrupt, and then clears the interrupt bit. 
         [0201]    In the case where a Tx that has not been completed has reached timeout, the backup host Y ( 100   b ) reissues this Tx (Step  1150 ). 
         [0202]    After the restoration processing of these steps is completed, the backup host Y ( 100   b ) operates as a new active host Y ( 100   b ) (Step  1160 ). 
         [0203]    A modification example of the first embodiment has now been described. 
       Second Embodiment 
       [0204]    A second embodiment of this invention is described below. 
         [0205]    A computer system in the second embodiment and its components including the hosts  100  and the multi-root PCI switch  200  have the same configurations as those in first embodiment. Descriptions on the components are therefore omitted here, and the focus is placed on differences from the first embodiment in the following description. 
         [0206]    In the second embodiment, new items are added to the virtual switch group management table  510 . 
         [0207]      FIG. 22  is an explanatory diagram illustrating a virtual switch group management table  510 - 2  according to the second embodiment of this invention. 
         [0208]    As shown in  FIG. 22 , failure settings  540  are newly added to each entry in the virtual switch group management table  510 - 2 . 
         [0209]    The failure settings  540  are made up of itemized settings for automatically switching the virtual switches  400  upon detection of a failure by the multi-root PCI switch  200 . Details of the failure settings  540  are described below. 
         [0210]      FIG. 23  is an explanatory diagram illustrating an example of the failure settings  540  according to the second embodiment of this invention. 
         [0211]    The failure settings  540  include a switched-to virtual switch number (switched-to VS #)  541 , an interrupt vector number (interrupt vector #)  542 , a switching factor  543 , a switching condition  544 , a watchdog timer threshold  545 , and a watchdog timer control register  546 . 
         [0212]    As the switched-to virtual switch number  541 , there is stored the virtual switch number  521  of the virtual switch  400  to which switching is made upon failover. Specifically, the virtual switch number  521  on the virtual switch list  513  that is not registered as the enabled virtual switch number  514  is stored as the switched-to virtual switch number  541 . 
         [0213]    As the interrupt vector number  542 , there is stored an identifier of an interrupt of which the backup host Y ( 100   b ) is notified when the virtual switches  400  are switched. 
         [0214]    The switching factor  543  and the switching condition  544  are specified in the form of bit map for each type of failure or reset that has caused the switching. The bit map set for each type of failure or reset that has caused the switching can be, for example, one described in the online document “Multi-Root I/O Virtualization and Sharing Specification Rev 1.0” published by PCI-SIG in May 2008, pp 109-222. 
         [0215]    Conceivable switching factors include: 
         [0216]    (1) the detection of reset in the virtual switches  400  that are used by the active host X ( 100   a ); 
         [0217]    (2) timeout of a watchdog timer; and 
         [0218]    (3) the detection of a failure in one of the virtual switches  400  that are used by the active host X ( 100   a ). 
         [0219]    The watchdog timer is a counter that, once starts counting, keeps counting up until cleared by the PCI manager  290  or the failover monitoring module  137  in the active host X ( 100   a ). The timer count is cleared periodically. 
         [0220]    In the case where the count of the watchdog timer exceeds the preset watchdog timer threshold  545  before cleared, this is interpreted as the indication of a failure in the active host X ( 100   a ), and an interrupt is made to notify that failover to the backup host Y ( 100   b ) is to be executed. 
         [0221]    The watchdog timer control register  546  includes, among others, the current timer count, a count-up enabled/disabled control flag, a timer count clearing bit, and a flag indicating a timer count overflow. 
         [0222]      FIG. 24  is a flow chart illustrating processing that is executed when the multi-root PCI switch  200  switches the virtual switches  400  upon detection of a failure in the host X ( 100   a ) according to the second embodiment of this invention. 
         [0223]    The multi-root PCI switch  200  determines a condition in accordance with conditions set as the switching condition  544  in the failure settings  540  (Step  1200 ). 
         [0224]    The multi-root PCI switch  200  refers to the switching condition  544  to determine whether or not reset monitoring is enabled (Step  1210 ). 
         [0225]    Determining that reset monitoring is enabled, the multi-root PCI switch  200  determines whether or not reset has been detected in the virtual switches  400  that are used by the active host X ( 100   a ) (hereinafter also referred to as active virtual switches  400 ) (Step  1220 ). The multi-root PCI switch  200  bases the determination on whether or not a reset notification from the active host X ( 100   a ) has been detected. 
         [0226]    In the case where reset is detected in the active virtual switches  400 , the multi-root PCI switch  200  proceeds to Step  1280 . 
         [0227]    In the case where reset is not detected in the active virtual switches  400 , the multi-root PCI switch  200  proceeds to Step  1230 . 
         [0228]    When it is determined in Step  1210  that reset monitoring is not enabled, the multi-root PCI switch  200  refers to the switching condition  544  to determine whether or not failure monitoring is enabled (Step  1230 ). 
         [0229]    Determining that failure monitoring is enabled, the multi-root PCI switch  200  determines whether or not a catastrophic failure that is irreparable has been detected in any one of the active virtual switches  400  (Step  1240 ). 
         [0230]    In the case where a catastrophic failure that is irreparable has been detected in any one of the active virtual switches  400 , the multi-root PCI switch  200  proceeds to Step  1280 . 
         [0231]    In the case where a catastrophic failure that is irreparable has not been detected in any one of the active virtual switches  400 , the multi-root PCI switch  200  proceeds to Step  1250 . 
         [0232]    When it is determined in Step  1230  that failure monitoring is not enabled, the multi-root PCI switch  200  refers to the switching condition  544  to determine whether or not watchdog timer monitoring is enabled (Step  1250 ). 
         [0233]    Determining that watchdog timer monitoring is not enabled, the multi-root PCI switch  200  returns to Step  1200  to continue monitoring. 
         [0234]    Determining that watchdog timer monitoring is enabled, the multi-root PCI switch  200  counts up on the watchdog timer (Step  1260 ) and determines whether or not the count of the watchdog timer has exceeded the watchdog timer threshold  545  (Step  1270 ). 
         [0235]    Determining that the count of the watchdog timer has not exceeded the watchdog timer threshold  545 , the multi-root PCI switch  200  returns to Step  1200  to continue monitoring. 
         [0236]    Determining that the count of the watchdog timer has exceeded the watchdog timer threshold  545 , the multi-root PCI switch  200  proceeds to Step  1280 . 
         [0237]    In Step  1280 , the multi-root PCI switch  200  records the cause of the switching as the switching factor  543 . 
         [0238]    The multi-root PCI switch  200  next overwrites the enabled virtual switch number  514  with the switched-to virtual switch number  541  set in advance (Step  1290 ). 
         [0239]    The multi-root PCI switch  200  then uses a vector specified by the interrupt vector number  542  to issue an interrupt to the virtual switch  400  to which the switching is made in Step  1290  (Step  1300 ). 
         [0240]    The backup host Y ( 100   b ) operates as a new active host Y ( 100   b ) from then on (Step  1310 ). 
         [0241]      FIG. 25  is a flow chart illustrating processing that is executed by the active host X ( 100   a ) according to the second embodiment of this invention. 
         [0242]    The active host X ( 100   a ) synchronizes with the backup host Y ( 100   b ) by copying information about the active host X ( 100   a ) to the backup host Y ( 100   b ) over the management network  270  at suitable intervals (Step  1400 ). 
         [0243]    The active host X ( 100   a ) determines whether or not watchdog timer monitoring is enabled (Step  1410 ). The determination can be made by the same method that is used in Step  1250  of  FIG. 24 . 
         [0244]    Determining that watchdog timer monitoring is not enabled, the active host X ( 100   a ) returns to Step  1400  to repeat the processing. 
         [0245]    Determining that watchdog timer monitoring is enabled, the active host X ( 100   a ) periodically accesses the watchdog timer control register  546  in the failure settings  540  to clear the timer count (Step  1420 ), and returns to Step  1400  to repeat the processing. In this manner, the watchdog timer is prevented from overflowing while the active host X ( 100   a ) is in operation. 
         [0246]      FIG. 26  is a flow chart illustrating processing that is executed by the backup host Y ( 100   b ) according to the second embodiment of this invention. 
         [0247]    The backup host Y ( 100   b ) obtains information about the active host X ( 100   a ) from the active host X ( 100   a ) over the management network  270 , and updates the information about the active host X ( 100   a ) at suitable intervals (Step  1500 ). 
         [0248]    The backup host Y ( 100   b ) determines whether or not an interrupt has been made (Step  1510 ). 
         [0249]    Determining that an interrupt has not been made, the backup host Y ( 100   b ) returns to Step  1500  to repeat the processing. 
         [0250]    Determining that an interrupt has been made, the backup host Y ( 100   b ) reads the switching factor  543  (Step  1520 ). This interrupt contains at least the interrupt vector number  542 . 
         [0251]    The backup host Y ( 100   b ) determines from the interrupt vector number  542  and the switching factor  543  whether or not the cause of the interrupt is one that accompanies the switching of the virtual switches  400  (Step  1530 ). 
         [0252]    Determining that the cause of the interrupt is not one that accompanies the switching of the virtual switches  400 , the backup host Y ( 100   b ) returns to Step  1500  to repeat the processing. Causes of the interrupt that are not the switching of the virtual switches  400  are processed by other functions of the backup host Y ( 100   b ). 
         [0253]    Determining that the cause of the interrupt is one that accompanies the switching of the virtual switches  400 , the backup host Y ( 100   b ) restores the interrupt state of the devices that are placed under the backup host Y ( 100   b ) (Step  1540 ). The restoration can be performed by the same method that is used in Step  1140  of  FIG. 21 . 
         [0254]    The backup host Y ( 100   b ) also reissues a Tx in the backup host Y ( 100   b ) that has reached timeout (Step  1550 ). 
         [0255]    The backup host Y ( 100   b ) operates as a new active host Y ( 100   b ) from then on. 
         [0256]    The second embodiment has now been described. 
         [0257]    According to one embodiment of this invention, in switching over from an active host where the PCI manager  290  is currently running to a backup host, the virtual switches  400  can be switched without resetting the MR devices  300 . 
         [0258]    An interim state that deviates from the MR-IOV specifications and unintended resetting of the MR devices  300  can thus be avoided. This enables the new active host to take over the virtual switches  400  used by other hosts as they are after the takeover, and the other hosts are accordingly not affected. 
         [0259]    According to another embodiment of this invention, it is possible to take over upon failure from an active host where the PCI manager  290  is currently running to a backup host, and the virtual switches can be switched without resetting the MR devices  300 . 
         [0260]    This keeps a failure in the active host from becoming a single point of failure, and prevents an interim state that deviates from the MR-IOV specifications and unintended resetting of the MR devices  300 . A highly reliable computer system can be built in this manner. 
         [0261]    While the present invention has been described in detail and pictorially in the accompanying drawings, the present invention is not limited to such detail but covers various obvious modifications and equivalent arrangements, which fall within the purview of the appended claims.