Abstract:
The present invention relates to a method, a computer program product and a system for managing virtual instances of a physical port attached to a network. The method is based on the Fibre Channel N_Port virtualisation for a physical Fibre Channel N_Port. Multiple virtual Fibre Channel adapters share a single physical N_Port among multiple operating system instances. The invention discloses means for the automatic and persistent generation and administration of unique Worldwide Port Names needed for the N_Port virtualisation.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    The present application is a continuation of U.S. patent application Ser. No. 11/479,847 filed on Jun. 30, 2006, which claims priority to European Patent Application No. 050105995.4, filed Jan. 7, 2005, and all the benefits accruing therefrom under 35 U.S.C. § 119, the contents of which in its entirety are herein incorporated by reference. 
     
    
     BACKGROUND OF THE INVENTION 
       [0002]    1. Field of the Invention 
         [0003]    The present invention relates to a method, a system, and a computer program product for managing virtual instances of a physical port attached to a network. 
         [0004]    2. Background Art 
         [0005]    More specifically, the invention relates to a network, in which each connected computer or device has a unique identifier. As an example, a network with Fibre Channel connections is described. 
         [0006]    Functionally, the Fibre Channel (FC) is a bi-directional, full-duplex, point-to-point, serial data channel structured for high performance data communication. The FC provides a generalized transport mechanism that has no protocol of its own or a native input/output command set, but can transport any existing Upper Level Protocols (ULPs) such as FCP, the “Fibre Channel Protocol for SCSI (Small Computer System Interface)”, and IP, the Internet Protocol. 
         [0007]    The smallest, indivisible unit of information transfer used by FC is called a frame. Frames are used for transferring data. The frame size depends on the hardware implementation and is independent of the ULP or the application software. These frames are aggregated to form messages called sequences. The frames of a sequence can be received out of order. One or more sequences form an exchange, which is a basic transaction. The frames are divided in two categories: link control frames without data payloads, which are used for the flow control, and data frames with data payloads such as encapsulated ULP data. 
         [0008]    Various FC standards exist, for example the following references:
       1. Information Technology—Fibre Channel Protocol for SCSI, 2 nd  Version (FCP-2), ANSI/INCITS 350   2. Information Technology—Fibre Channel Framing and Signalling Interface (FC-FS), ANSI/INCITS 373.       
 
         [0011]    Further details about FC can be found for example in Robert W. Kembel, “The Fibre Channel Consultant—A Comprehensive Introduction”, 1998. 
         [0012]    Connecting a computer or other device to a FC requires specific hardware. FC hardware is usually provided in the form of FC adapter cards which are plugged in existing input/output (I/O) hardware such as PCI/PCI-X/PCI-Express slots of a computer system. Every FC adapter contains at least one N_Port, a FC hardware entity which performs the actual data communication over the FC link. 
         [0013]    An N_Port is identifiable by a unique Worldwide Port Name (WWPN) implemented as a 64-bit value. This WWPN is normally assigned at manufacturing time of the FC hardware, but may also be assigned by other means, provided that the port name can be guaranteed to be unique worldwide. An N_Port can act as an originator or a responder. 
         [0014]    FC connections may be implemented as a point-to-point link, or an arbitrated loop or a switching network, called a fabric. 
         [0015]    A FC fabric is an interconnection network that allows multiple N_Ports to intercommunicate. The entry/exit ports on a fabric are called F_Ports, and each N_Port has to connect to one F_Port. The fabric allows each connected N_Port to communicate with any other N_Port that is attached to the fabric. 
         [0016]    The FC fabric assigns to each attached N_Port an identifier, which is an address by which an N_Port is uniquely known for the fabric. Since the N_Port identifier is a 24-bit value, a FC fabric can support up to 16.7 million N_Ports. The N_Port identifier consists of a Domain (most significant byte), an Area, and a Port, each 1 byte long. The N_Port identifier is used in the Source Identifier (S_ID) and Destination Identifier (D_ID) fields of the header of a FC frame. 
         [0017]    Initiating communications in a fabric requires a multistage login process in which communications are first established between an N-port and an F-port in the fabric and then with the destination N-port. In the first step, the fabric login of the N_Port establishes the classes of service to be used within the fabric and other communications parameters including flow control information. After the fabric login of the N_Port completes, the initiating and recipient N-ports in the network establish communications with each other through a second login process called node logic Several communication parameters are exchanged and the transmission starts. As FC can be used to connect systems with multiple types of internal resources and processes within, an additional login called a process login is used. For example, the process login is used to select parameters related to an ULP supported by processes within two communicating N_Ports. 
         [0018]    The vast majority of today&#39;s FC adapters provide one N_Port only. In a computer executing multiple operating system (OS) instances, the problem occurs how to share such an N_Port among these instances. Such sharing would be advantageous to minimize the number of FC adapters, to reduce cost and to maximize adapter utilization, especially for large scale virtualisation environments. The problem exists even when using FC adapters providing multiple N_Ports since the number of processes needing to be supported often exceeds the number of N_Ports provided by the FC adapters. 
         [0019]    The capability to execute multiple OS instances is usually provided by a software layer called (execution) hypervisor that encapsulates the underlying hardware and provides virtual hardware interfaces either for the underlying hardware or for different hardware architectures. For example, a hypervisor can be part of the firmware of a computer system, it can be part of an operating system, or it can be a regular program running as a process within an OS instance. The work of the hypervisor is often supported by additional hardware features, for example special processor instructions or firmware layers. 
         [0020]    Some hypervisors can effectively create multiple virtual images of a computer system, giving an OS instance executing in such a virtual computer system almost the illusion as if it was running exclusively on the real server. These OS instances access real I/O entities (like adapters) via I/O ports, which can be defined and assigned to a virtual computer system in a configuration step. An OS instance may only perform I/O operations using I/O ports assigned to the particular virtual server on which it is running. 
         [0021]    The U.S. patent applications No. 2003/0200247A1 and No. 2004/0025166A1 describe a method for the concurrent sharing of a FC adapter among multiple OS instances in a computer system. However, this sharing capability has various deficiencies caused by the fact that the same N_Port identifier is used for all FC frames sent from or destined to a particular FC adapter. Consequently, this N_Port identifier cannot be used to distinguish multiple OS instances: All of the frames seem to come from the same initiator, and responses are accordingly sent back to the same address. The solution proposed in the above patent applications is to intercept, analyse, and modify the FC frame traffic between the multiple OS instances and the physical N_Port. 
         [0022]    A major disadvantage is that this solution is host-based, which means that the approach needs to be performed on a host computer system that is attached to a FC fabric. Since FC is a technology used mainly for Storage Area Networks (SAN), and the usual method for access control in the SAN and its attached storage devices is managed by the SAN itself (using databases stored in the fabric), this adds additional complexity to the SAN management and administration. 
         [0023]    Another disadvantage is that it is not possible to initiate a FC transaction to a particular OS instance from outside of the computer system executing the multiple OS instances. This limitation is caused by the need for the unequivocal response identifier that gets added to the frame header when it gets intercepted. There is only one response identifier to be used for frames that will be sent to a particular OS instance. Without being able to identify the specific OS instance, any incoming frame has to be forwarded to every OS instance. An OS instance needs to decide then if it will accept and process the frame. 
         [0024]    Other deficiencies that exist in such a shared adapter environment are related to ULPs such as FCP; for example, SCSI reservations do not work properly, correct SCSI status and sense data handling cannot be guaranteed, SCSI task management functions do not work properly, and vendor-unique SCSI commands might not work at all. 
         [0025]    SAN access control for the connected storage controllers of a fabric is typically implemented by methods like zoning and SCSI Logical Unit (LUN) masking. Zoning and LUN masking rely on WWPNs to identify users of controlled assets. Using a LUN and FCP as the ULP, a FC host can address multiple peripheral devices that may share a common controller. Zoning allows partitioning the N_Ports of a fabric into N_Port groups, called zones. The N_Port within a zone can only communicate with other N_Ports in the same zone. 
         [0026]    One way to solve the FC adapter sharing problem was disclosed in the U.S. patent application No. 2003/0103504A1 and later on incorporated in the INCITS/ANSI FC Framing and Signalling (FC-FS) standard 1.6, which describes how a fabric needs to handle N_Port identifier virtualisation. The application describes a method to obtain multiple N_Port identifiers (N_Port IDs) for a single physical N_Port. 
         [0027]    In order to obtain an N_Port identifier, the N_Port first logs in with the fabric by sending a “Fabric Login” (FLOGI) extended link service (ELS) command (a special link control frame) to the attached F_Port. In this step additional service parameters will be transferred, and the first N_Port identifier is assigned. After FLOGI is complete, the fabric prepares itself to assign additional N_Port identifiers. In order to obtain another N_Port identifier, the N_Port sends a “Fabric Discover” (FDISC) ELS command using an S_ID of zero. The FDISC ELS is used instead of additional FLOGI commands to avoid disruption of the operating environment. When the N_Port sends the FDISC ELS to the fabric, it provides the following functions:
       1. It provides the means for the physical N_Port to transfer a WWPN to the fabric.   2. It provides a signal to the fabric to validate and assign an additional N_Port identifier for the physical N_Port, and allows both the fabric and the physical N_Port to begin normal frame reception and transmission using the new N_Port identifier.   3. It provides a signal which causes the fabric to update databases maintained within the fabric.       
 
         [0031]    When the new N_Port ID has been assigned, the physical N_Port can associate the new N_Port ID with a virtual adapter, which is an entity behind the physical N_Port that generates and receives frames using the new N_Port ID on behalf of an OS instance. Therefore, multiple virtual adapters can be associated with a physical adapter and its N_Port, where each virtual adapter uses a unique N_Port ID. 
         [0032]    The assignment of new N_Port IDs requires the availability of unique WWPNs and means for the automatic and persistent assignment of these WWPNs to virtual adapters, where persistent can mean surviving e.g. a reboot of an OS instance, a power-off/power-on cycle of the computer system, or a reboot of a FC adapter. In large scale computer centres with complex SAN installations it can become therefore a very complex task to ensure that every WWPN in use is really unique. 
       SUMMARY OF THE INVENTION 
       [0033]    It is therefore an object of the present invention, to provide a method for managing virtual instances of a physical port attached to a network that is improved over the prior art and a corresponding computer system and a computer program product. 
         [0034]    This object is achieved by the invention as defined in the accompanying claims  1 ,  9 ,  10  and  12 . 
         [0035]    The present invention proposes a FC adapter virtualisation entity that can be used to provide multiple virtual FC adapters for a single physical FC adapter as a way to share this FC adapter among multiple OS instances. Each virtual adapter has a single N_Port ID. If the physical FC adapter has multiple physical N_Ports, then independent sets of virtual adapters can be associated with each of the N_Ports of that physical adapter. 
         [0036]    The FC adapter virtualisation entity obtains a WWPN for each I/O port that is defined in a hypervisor system configuration from a FC virtual adapter name controller entity. This entity may create a WWPN using a scheme or just take it from a pool of WWPNs. It is possible that the WWPN of a physical N_Port of the physical FC adapter is used for a virtual FC adapter. The FC virtual adapter name controller ensures the worldwide uniqueness for a WWPN that it provides. 
         [0037]    A virtual FC adapter may be created when an OS instance activates an I/O port, or it maybe created in advance in order to save the time for its initialisation, and be associated to the I/O port when that I/O port is activated. In any case, when the virtual adapter is associated to an I/O port, it uses the WWPN of that I/O port in order to perform a fabric login using the FDISC ELS command and to acquire a corresponding FC N_Port ID. The WWPN remains associated with the virtual adapter as long as the virtual adapter is tied to that particular I/O port. 
         [0038]    The association of an I/O port and its WWPN can be made persistent by storing related tables on a storage device coupled to the computer system. This way a power-off/power-on cycle of the computer system or a restart of the hypervisor has no influence to the mapping of a WWPN to an I/O port. The WWPN, through the issuance of FDISC and the assignment of an N_Port ID for the WWPN, ensures that only properly authorized virtual servers and operating system instances can reach their assigned resources. 
         [0039]    The present invention allows sharing a single physical FC adapter among multiple OS instances transparently. The adapter is shared automatically without any special commands required by the OS instances. 
         [0040]    A further important aspect of the invention is that it supports the regular SAN management and administration models such as zoning and LUN masking transparently. This avoids host-based SAN management and administration steps and the attendant problems previously described. This also reduces the SAN management and administration complexity significantly. This eliminates restrictions for ULPs such as FCP. 
         [0041]    Another aspect of the invention is that a FC transaction using a virtual adapter can get initiated from outside of the computer system and directed to a particular OS instance. 
         [0042]    The invention allows defining virtual adapter characteristics, for example performance characteristics such as adapter bandwidth. This allows balancing between the virtual adapters that share the same physical N_Port based on the performance needs of each virtual adapter. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0043]    For the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings. 
           [0044]      FIG. 1 : Is a block diagram of a computer system into which the invention can be implemented; 
           [0045]      FIG. 2 : Is a block diagram of the encapsulation of a FC adapter by a hypervisor that controls multiple OS instances; 
           [0046]      FIG. 3 : Is a block diagram of a hypervisor embodiment in accordance with the invention; 
           [0047]      FIG. 4 : Is an illustrative flow chart of an embodiment of a method in accordance with the invention; 
           [0048]      FIG. 5 : Is an illustrative flow chart of an embodiment of a method in accordance with the invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0049]      FIG. 1  illustrates a computer system  10  in which the present invention can be used. A shared memory  11  is coupled to one or more Central Processing Units (CPUs)  12 . These CPUs  12  are also coupled to an I/O subsystem  13 . A separate storage device  14  can also be accessed by the CPUs  12 . The content of the storage device  14  is persistent: It survives a power off/power-on cycle. A FC adapter  15  is accessible for the CPUs  12  via the I/O subsystem  13 , and this FC adapter  15  is connected to a FC fabric  16 . The FC adapter  15  has a physical N_Port  17  that is connected to an F_Port  18  of the fabric  16 . 
         [0050]    As shown in  FIG. 2 , the computer system is running a hypervisor  20  on the CPUs  12 , which controls multiple OS instances  21  that are executed concurrently. The hypervisor  20  emulates the FC adapter  15 ; the OS instances  21  perceive the normal FC adapter interface, but in fact have I/O requests processed through the hypervisor  20  in order to access the FC adapter  15 . The component of the hypervisor that is responsible for the interface to the OS instances  21  is called the virtual machine interface (VMI)  22 . The VMI  22  can be any kind of computer interface usable by software. In the preferred embodiment of the invention the storage device  14  is used to store internal data of the hypervisor  20  and not directly accessible by the OS instances  21 . 
         [0051]    A FC Adapter Virtualisation Entity (AVE)  30  is now implemented as a component of the hypervisor  20  shown in  FIG. 3 . Its purpose is to intercept I/O requests from the OS instances  21  accessing the FC adapter  15 . Typically, an OS instance  21   a  makes I/O requests in a communication unit  31 . Such a communication unit  31  can be implemented as a device driver for example. 
         [0052]    The communication unit  31  uses an I/O port  32  to communicate with a FC adapter  15 . For the purposes of the present invention it is sufficient that the I/O port  32  comprises a request queue and a response queue. These queues will be used by the AVE  30  and the communication unit  31 . The communication unit places requests for the FC adapter  15  in the request queue. A request contains addresses of the memory  11  that allow the AVE  30  to access data stored in the memory  11  that can be associated with such a request. This data comprises FC frames that will be forwarded by the AVE  30  to the FC adapter  15 . The hypervisor  20  places responses from the FC adapter  15  in the response queue. A response contains addresses of the memory  11  that allow the communication unit to access data stored in the memory  11  by the hypervisor  20 . The data in the memory  11  also comprises FC frames that have been received by the FC adapter  15 . 
         [0053]    In order to use an I/O port  32  it needs to be activated by a communication unit  31  as it would without the present invention. For every activated I/O port  32 , the AVE  30  creates special data structures in the memory  11 . These data structures are called a virtual FC adapter. Among associated interfaces of the hypervisor  20  are interfaces that allow an OS instance  21   a  to send and receive FC frames. The special data structures are used for the implementation of these interfaces. 
         [0054]    During the I/O port activation, the AVE  30  obtains a new N_Port identifier from the fabric  16  (as described earlier) that is associated with the I/O port  32  and stored in the corresponding virtual adapter. For each frame that is sent from a communication unit  31  using this I/O port  32  the AVE  30  puts the N_Port ID associated with this I/O port  32  in the S_ID field of the FC frame header. Accordingly, all FC frames received by the AVE  30  from the fabric  16  that carry this N_Port ID in the D_ID field of the frame header are forwarded via this I/O port  32  to the corresponding OS instance  21   a.    
         [0055]    An I/O port  32  is generated by the hypervisor  20  in a special system configuration step. In this step, the AVE  30  uses a Virtual Adapter Name Controller (VA-NC)  33  entity to assign a WWPN to the I/O port  32 . The VA-NC  33  maintains a pool  34  of WWPNs, from which it takes one WWPN that is assigned to the I/O port  32  and removed from the pool  34 . WWPNs that have been assigned to an I/O port  32  are maintained by the VA-NC  33  in a table  35  called the Virtual Adapter Name Assignment Table (VA-NAT), which is stored on the persistent storage device  14 . In the system configuration step the association of an I/O port  32  to an OS instance  21   a  is also defined. There is no restriction that a communication unit  31  can use one I/O port only. 
         [0056]    The steps for the I/O port  32  activation are shown in  FIG. 4 . The communication unit  31  triggers the activation of the I/O port  32  (step  40 ). If (step  41 ) the I/O port  32  is already activated, then (step  42 ) the AVE  30  presents an error to the communication unit  31 . Otherwise the WWPN of the I/O port  32  will be used to log in the fabric  16  using the FDISC ELS command (step  43 ). If (step  44 ) the login is not successful, then (step  45 ) the AVE  30  presents an error to the communication unit. Otherwise the AVE  30  marks the I/O port  32  as activated, stores the N_Port ID provided by the fabric  16  in the virtual adapter (step  46 ), and returns to the communication unit  31  (step  47 ). 
         [0057]      FIG. 5  shows the steps for the I/O port  32  deactivation. The communication unit  31  triggers the deactivation of an I/O port  32  (step  50 ). If (step  51 ) the I/O port  32  is not activated, the AVE presents an error to the communication unit  31  (step  52 ). Otherwise the N_Port ID associated to the I/O port  32  will be logged out of the fabric  16  (step  53 ) using well-known methods described in reference  2 . If (step  54 ) the logout is not successful, then the AVE  30  presents an error to the communication unit  31  (step  55 ). Otherwise (step  56 ) the I/O port  32  will be marked as deactivated, and the associated N_Port ID entry for the WWPN will be deleted in the virtual adapter. Afterwards the AVE  30  finishes the deactivation successfully (step  57 ). 
         [0058]    I/O ports that have been generated in a configuration step of the hypervisor  20  can be removed from the system configuration. If an I/O port is removed from the system configuration, the corresponding WWPN is added to the pool of WWPNs  34  again and marked as “locked”. The VA-NC  33  will not use a WWPN that is marked “locked” for the assignment to a newly created I/O port  32 , i.e. I/O ports that are subsequently added to the system configuration. 
         [0059]    The locking of a WWPN when its associated I/O port  32  has been removed from the system configuration of the hypervisor  20  has to be done in order to avoid that this WWPN could be assigned again to another I/O port  32  that gets added to the system configuration of the hypervisor  20 . This would be the case if access rules are still established in the SAN for this WWPN, for example a LUN mask setting granting this WWPN access to certain devices (LUNs). But often such a re-use of a WWPN with a new I/O port is not intended, as only certain OS instances are meant to use certain resources in the SAN. 
         [0060]    Therefore, to recover these locked WWPNs, and to prevent the situations where no WWPN can be assigned to an I/O port because all available WWPNs are either locked or in use, the VA-NC  33  adds an interface to the hypervisor  20  that allows unlocking a WWPN. So for example a system administrator can unlock a WWPN for which it was verified that no unintended access rights are in place, and therefore it is safe to reassign this WWPN to an I/O port  32  that can be assigned to any operating system instance  21   a.    
         [0061]    In an embodiment of the invention, WWPNs that were associated to I/O ports that have been removed from the system configuration of the hypervisor  20  are added to a least-recently-used list  36  stored in the memory  11  (or on the persistent storage device  14 ). 
         [0062]    This least-recently-used list  36  is implemented as a first-in first-out list. An entry of this list  36  contains a WWPN together with an identifier for the I/O port  32  to which the WWPN was assigned. Should the same I/O port  32  (as indicated by the identifier) be redefined again while the corresponding WWPN is still in the least-recently-used list  36 , then the same WWPN will be assigned to that I/O port  32  again. This way there is no need to reconfigure the SAN as would be the case when an I/O port  32  is temporarily removed from the system configuration of the hypervisor  20 , and another WWPN would be assigned to the I/O port  32  when the I/O port  32  gets added to the system configuration of the hypervisor  20  again. 
         [0063]    The length of the least-recently-used list  36  may be limited such that not all possible WWPNs that fall out of the AV-NAT  35  can be kept in this table. If a WWPN falls out of the least-recently-used list, it will be added to the pool of WWPNs  34  again and still remain marked as “locked”. Instead of maintaining the least-recently-used list  36  as a first-in first-out list, various other strategies are possible for the decision to remove an entry from the list  36 . 
         [0064]    The use of the least-recently-used list  36  may save a considerable amount of the memory  11  for large and dynamically changing system configurations of the hypervisor  20  as all the memory allocated for the special data structures of the virtual adapters associated with the locked WWPNs can be released. Otherwise it would be required to keep the I/O ports and their associated virtual adapters in order to avoid the SAN reconfiguration. 
         [0065]    The WWPNs stored in the pool  34  are assigned to the computer system  10  and the pool  34  is stored on the persistent storage device  14 . If the WWPNs do not need to be worldwide unique because they will be used in a configuration that is completely isolated from all other SANs, the VA-NC  33  can also use a scheme to generate a WWPN for a new I/O port definition instead of taking it out of the pool  34  of WWPNs. A possible scheme is to use a common prefix that will be combined with an identifier for the I/O port  32 . 
         [0066]    A scheme can also be used to generate WWPNs that are really unique worldwide. For this scheme a worldwide unique prefix would be assigned to the computer system  10 , and this prefix would be combined with the identifier for the I/O port  32  for example. In yet another embodiment, the physical N_Port and its associated WWPN is used in shared mode as described in the U.S. patent application No. 2003/0200247A1, using the access control mechanism as described in the U.S. patent application No. 2004/0025166A1. This can be exploited if the number of OS instances  21  that need to concurrently share a physical N_Port is larger than the number of virtual adapters that can be supported on the physical N_Port. In another embodiment, also one or more virtual adapters with their associated configured WWPNs can be used as shared virtual adapters in the same way. 
         [0067]    In one embodiment of the present invention the VA-NC  32  adds an interface to the hypervisor  20  that allows querying for the WWPN and the N_Port ID currently assigned to an I/O port. This can be used by an OS instance  21   a  for SAN management and administration purposes. 
         [0068]    The first login from a physical N_Port  17  to the fabric  16  must always be done using the FLOGI ELS command. In one embodiment, the WWPN assigned to the physical N_Port  17  is used for this FLOGI-type login. Although the FC-FS standard (see reference  1 ) would allow the logout of the N_Port  17 , which did the FLOGI login from the fabric  16  while other fabric  16  logins from virtual adapters associated with the N_Port  17  are still active, it may cause problems when the N_Port  17  is logged in the fabric  16  again. The reason is that the WWPN specified with the FLOGI is used as a permanent port name for the physical N_Port, and remains associated with this N_Port and maintained by the fabric  16  as long as any login for this physical N_Port is still active. Specifically, if the FLOGI login is revoked by a corresponding logout while an FDISC login is still active, and now the WWPN used previously for the FLOGI login is used for another login into the fabric  16 , the fabric  16  may see the same WWPN twice, which may cause disturbances to SAN management applications. 
         [0069]    Therefore, in an embodiment of the invention the N_Port ID assigned by the fabric  16  for the WWPN of the N_Port  17  used for the FLOGI-type login is not logged out (see step  54 ) during the deactivation of an I/O port  32  associated to this N_Port ID when additional N_Port IDs for this physical N_Port are still logged in the fabric  16 , which means that I/O ports  32  associated to these N_Port IDs are still active. 
         [0070]    It is possible that an N_Port can become disconnected from the fabric  16 . If this occurs all the FC frames for incomplete exchanges using the N_Port are invalidated and all the N_Port IDs are automatically logged out of the fabric  16 . Depending on its type, a disconnection is indicated by the FC adapter  15  by either sending a FC frame indicating unsolicited status to the AVE  30  or by storing a special value in a register of the FC adapter  15  that is accessible for the AVE  30 . The AVE  30  informs an affected OS instance  21   b  that its virtual adapters have been logged out. For each N_Port ID that was logged out as a result of the disconnection, the affected communication units  31  need to deactivate their affected I/O ports  32  and activate them again. 
         [0071]    In order to minimize the impact of an N_Port disconnection to application programs in an OS instance  21   b  affected by that disconnection, I/O ports  32  can be prioritized for re-activation. A simple prioritisation solution is that the AVE  30  uses a priority list of I/O ports in the memory  11  that were active before. For every I/O port  32  activation, the AVE  30  searches this priority list and if it finds the I/O port in the priority list (that is, the activation is a re-activation of a disconnected I/O port), the activation continues immediately. Otherwise the AVE  30  waits a certain amount of time before it continues the activation so as to not consume an N_Port ID before a previously-active I/O port can be re-activated. An entry in the priority list is deleted when it is found during I/O port activation, and it is removed after some expiration time. 
         [0072]    Further, it is possible to define characteristics for a virtual adapter. For example, it is possible to define certain performance characteristics in order to balance between the virtual adapters that share the same physical N_Port  17  based on the performance needs of each OS instance  21   a  using the virtual adapters; e.g. a “high bandwidth” could define the use of bigger memory buffers by the AVE  30  in order to increase the bandwidth for a virtual adapter; “low bandwidth” could define the use of small memory buffers by the AVE  30  in order to decrease the bandwidth for a virtual adapter. 
         [0073]    The separate storage device  14  does not need to be directly attached to the computer system  10 . It can also be attached to another computer system that provides indirect access to this storage device  14  via a network service for example. 
         [0074]    This invention is preferably implemented as software, a sequence of machine-readable instructions, especially as so-called firmware executing on one or more hardware machines that controls and monitors these hardware machines and is often used to implement well-defined interfaces to the hardware, which other programs (especially operating systems) can use. 
         [0075]    While a particular embodiment has been shown and described, various modifications of the present invention will be apparent to those skilled in the art.