Abstract:
Method and system for converting identifier information after a driver upgrade is provided. The method includes updating a driver for a peripheral device in a storage area network, wherein a first driver is replaced by a second driver and the peripheral device is operationally coupled to one or more target device; reading identifier information for the target devices; and converting identifier information for the target device from a format supported by the first driver to a format supported by the second driver.

Description:
BACKGROUND 
     1. Field of the Invention 
     The present invention relates to storage systems, and more particularly, to managing storage systems. 
     2. Background of the Invention 
     Storage area networks (“SAN”) are commonly used to store and access data. SAN is a high-speed sub-network of shared storage devices, for example, disks and tape drives. A computer system (may also be referred to as a “host”) can access data stored in the SAN. 
     Typical SAN architecture makes storage devices available to all servers that are connected using a computer network, for example, a local area network or a wide area network. The term server in this context means any computing system or device coupled to a network that manages network resources. For example, a file server is a computer and storage device dedicated to storing files. Any user on the network can store files on the server. A print server is a computer that manages one or more printers, and a network server is a computer that manages network traffic. A database server is a computer system that processes database queries. 
     Efforts are being made to upgrade drivers/software systems to manage SANs and SAN components. One challenge with changing drivers is that certain SAN based information gets lost when a system migrates from one driver to another driver. Therefore, there is a need for a method and system to automatically update information when new driver/software is used. 
     SUMMARY OF THE INVENTION 
     In one aspect of the present invention, a method for converting identifier information after a driver upgrade is provided. The method includes updating a driver for a peripheral device in a storage area network, wherein a first driver is replaced by a second driver and the peripheral device is operationally coupled to one or more target device; reading identifier information for the target devices; and converting identifier information for the target device from a format supported by the first driver to a format supported by the second driver. 
     In another aspect of the present invention, a host computing system operationally coupled to a peripheral device that is operationally coupled to plural target devices via a storage area network (“SAN”) is provided. The host computing system includes a processor for executing a management application for managing plural SAN components; and a driver for communicating with the peripheral device, wherein the driver is updated from a first driver to a second driver, and the first driver is replaced by the second driver and identifier information for the target devices is converted from a format supported by the first driver to a format supported by the second driver. 
     This brief summary has been provided so that the nature of the invention may be understood quickly. A more complete understanding of the invention can be obtained by reference to the following detailed description of the preferred embodiments thereof concerning the attached drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The foregoing features and other features of the present invention will now be described with reference to the drawings of a preferred embodiment. In the drawings, the same components have the same reference numerals. The illustrated embodiment is intended to illustrate, but not to limit the invention. The drawings include the following Figures: 
         FIG. 1A  shows a top-level system diagram with a host system running a management application, according to one aspect of the present invention; 
         FIG. 1B  shows the internal architecture of the host system of  FIG. 1A ; 
         FIG. 1C  shows a top-level software architecture using a management application, according to one aspect of the present invention; 
         FIG. 1D  shows an example of target persistent information that is formatted, according to one aspect of the present invention; 
         FIG. 2  is a process flow diagram for maintaining target persistent data, according to one aspect of the present invention; and 
         FIGS. 3-7  are screen shots showing how target data is maintained after driver migration, according to one aspect of the present invention. 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     To facilitate an understanding of the preferred embodiments, the general architecture and operation of a system using storage devices and various standards will be described. The specific architecture and operation of the preferred embodiment will then be described with reference to the general architecture. 
     Various components and standard interfaces are used to move data from host systems to storage devices in a SAN. Fibre channel is one such standard. Fibre channel (incorporated herein by reference in its entirety) is an American National Standard Institute (ANSI) set of standards, which provides a serial transmission protocol for storage and network protocols such as HIPPI, SCSI (small computer system interface), IP, ATM and others. Fibre channel provides an input/output interface to meet the requirements of both channel and network users. 
     Host systems often communicate with storage systems in a SAN via a host bus adapter (“HBA”) using the “PCI” bus interface. PCI stands for Peripheral Component Interconnect, a local bus standard that was developed by Intel Corporation®. The PCI standard is incorporated herein by reference in its entirety. PCI-X/PCI-Express are other standard buses that provide a better throughput than PCI. Both the PCI-X/PCI-Express standards are incorporated herein by reference in their entirety. 
     The iSCSI standard (incorporated herein by reference in its entirety) is based on Small Computer Systems Interface (“SCSI”), which enables host computer systems to perform block data input/output (“I/O”) operations with a variety of peripheral devices including disk and tape devices, optical storage devices, as well as printers and scanners. A traditional SCSI connection between a host system and peripheral device is through parallel cabling and is limited by distance and device support constraints. For storage applications, iSCSI was developed to take advantage of network architectures based on Fibre Channel and Gigabit Ethernet standards. iSCSI leverages the SCSI protocol over established networked infrastructures and defines the means for enabling block storage applications over TCP/IP networks. iSCSI defines mapping of the SCSI protocol with TCP/IP. 
     The iSCSI architecture is based on a client/server model. Typically, the client is a host system such as a file server that issues a read or write command. The server may be a disk array that responds to the client request. Devices that request I/O processes are called initiators. Targets are devices that perform operations requested by initiators. Each target can accommodate up to a certain number of devices, known as logical units, and each is assigned a Logical Unit Number (LUN). 
       FIG. 1A  shows an example of a host system  100  coupled to a SAN  103  via a HBA  102 . Host system  100  can access storage devices (may also be referred to as targets)  104  and  105  via HBA  102 . It is noteworthy that a host system  100 , as referred to herein, may include a computer, server or other similar devices, which may be coupled to storage systems. 
     Management application  101  runs on host system  100  or remotely. Storage vendors use management applications to manage SAN components. One such application is the QLogic SanSurfer FC HBA Manager that is provided by QLogic Corporation, the assignee of the present application. Management application  101  is described below with respect to  FIGS. 2-7 . 
       FIG. 1B  is a block diagram showing the internal functional architecture of host system  100 . As shown in  FIG. 1B , host system  100  includes a microprocessor or central processing unit (“CPU”)  106  that interfaces with a computer bus  106 A for executing computer-executable process steps. Also shown in  FIG. 1B  are a network interface  107  that provides a network connection, and an adapter interface  108  that interfaces host system  100  with adapter  102 . It is noteworthy that interface  107  and  108  may be a part of adapter  102  and the present invention is not limited to any particular type of network or adapter interface. 
     Host system  100  also includes a display device interface  113 , a keyboard interface  114 , a pointing device interface  110 , and a storage device  109  (for example, a disk, CD-ROM or any other device). 
     Storage  109  may store operating system program files, application program files (for example, management application  101 , according to one aspect of the present invention), and other files. Some of these files are stored on storage  109  using an installation program. For example, CPU  106  executes computer-executable process steps of an installation program so that CPU  106  can properly execute the application program. 
     A random access main memory (“RAM”)  111  also interfaces with computer bus  106 A to provide CPU  106  with access to memory storage. When executing stored computer-executable process steps from storage  109 , CPU  106  stores and executes the process steps out of RAM  111 . 
     Read only memory (“ROM”)  112  is provided to store invariant instruction sequences such as start-up instruction sequences or basic input/output operating system (BIOS) sequences for operation of a keyboard (not shown). 
     Computing systems typically use an operating system that provides an interface between application programs and hardware connected to the computing systems. The operating system typically uses a device driver to interface with a peripheral device. The driver provides a set of routines/sub-routines that implements device specific aspects of input/output (I/O) operations. 
       FIG. 1C  shows a layered software architecture that is typically used by a host system  100  to interact with SAN components. This architecture is commonly used in the Windows environment. Management application  101  interfaces with device  102  (or HBA  102 ) via an agent  115 . Agent  115  is a program routine that interfaces between management application  101  and an application program interface (API)  116 . API  116  interfaces with a driver  117  that allows interfaces with device  102  (device  102  firmware). The term driver as used herein includes software code that allows an operating system/application to interface with a device. 
     Microsoft Corporation® that markets Windows Server 2003® and Windows Storage Server 2003® provides certain storage drivers/software ( 117 ). One such driver is the SCSI device driver that is provided by Microsoft Corporation. The SCSI device driver includes a class driver, a SCSIport driver and a SCSI miniport driver. The SCSIport driver translates an input/output (I/O) request into a SCSI request block (SRB) and queues it to the miniport driver, which decodes the SRB and translates it into a specific format required by the HBA. 
     A new driver called the “Storport” driver is now being provided that has better performance than the SCSIport driver. Storage vendors, i.e., companies that make storage devices and HBAs are being encouraged to use the Storport driver instead of the SCSIport driver. 
     When a user migrates from the SCSIport driver to the Storport driver, the user can lose vital information for managing the SAN. A user then will have to enter the data manually into the upgraded system (i.e. the system using Storport Driver). One such element or piece of information that is lost is a part of “target persistent” data. Target persistent data includes information that is used to uniquely identify a target (for example,  104  and  105 ), as described below in detail. In one aspect of the present invention, a method and system is provided that updates target persistent binding data so that manual entry is not required. 
       FIG. 1D  shows an example of target persistent data  118  that is used to manage storage devices in a SAN. Data  118  has various components/fields, for example: (a) Device type  119  indicates the type of storage device; (b) Device Information  120  provides information about the device, for example, a manufacturer&#39;s name and product number; (c) Port Name  121  is a unique World Wide Name (WWN) that is assigned to a target coupled via a port of HBA  102 ; (d) Port Identifier  406  (also shown as  121  in  FIG. 1D ) is unique port identifier for the target that is accessible by HBA  102 ; and (e) Target Identifier (ID)  123  is a value that is assigned to the target and is shorter than the WWN. It is the Target ID value ( 123 ) that can be lost when a user migrates from the SCSIport driver to the STORport driver or vice-versa, and the present invention solves this problem, as described below with respect to  FIG. 2  and the screen shots shown in  FIG. 3-7 . 
     Turning in detail to  FIG. 2 , the process of upgrading a driver (for example, to replace a SCSIport driver by a STORport driver) starts in step S 200 . In step S 201 , the SCSIport driver is updated and replaced by STORport driver. If the update is not successful, as determined in step S 202 , the process stops in step S 203  or is restarted. 
     If the update is successful, then target persistent data is read from the Windows Registry (stored in storage  109 ). The Windows registry is maintained by the Windows Operating system and stores configuration information. In step S 205 , the target persistent data is converted into a format that is recognized by the new driver, i.e., the STORport driver. The management application  101  performs the conversion. The process ends in step S 206 . Without the conversion, one will have to manually enter the target persistent information into the Windows Registry. This is a tedious task, especially since the target ID information is stored as binary data in the Windows Registry. 
       FIGS. 3-7  show screen shots using management application SANsurfer FC HBA Manager provided by QLogic Corporation, the assignee of the present application, according to one aspect of the present invention. This application is run on a host computing system, similar to system  100 . The screen shots are provided only as an example and the present invention is not limited to the layout or any other feature of the user interface. 
       FIG. 3  provides a user interface where the “device list”  301  is highlighted (or selected by a user). The device in this instance is a HBA model number QLA2312 with port  0  (shown as  300 ) and port  1 . The driver used in this screen shot is SCSI Miniport  302 . 
       FIG. 4A  provides an interface when the user selects “target persistent” tab  401 . The user is shown segments  402 - 407 . Segment  402  allows a user to select the option “bind”. This selection will bind a particular target to port  1  (shown as  400 ). The type of target (shown as disk) is provided in segment  403 . Device information  404  provides the device model number. Port name is provided in segment  405  and port ID is provided in segment  406 . The target ID  407  is an identifier that identifies the target with a value that is smaller than port name.  FIG. 4B  shows the target IDs  3 ,  2 ,  1 , and  0  for the various devices.  FIG. 4B  also shows that the user has selected the “bind” option. The target ID information is shown in the Windows registry and is shown in  FIG. 4C  as item  408 . Once the user migrates to the STORport driver, the target ID values are typically lost. The present invention solves this problem, as shown in  FIGS. 5-7 . 
       FIG. 5  is similar to  FIG. 3 , except the driver is STORport (shown as  502 ). The device list  501  is similar to  301  and item  500  in  FIG. 5  is similar to  300  in  FIG. 3 .  FIG. 6  is similar to  FIG. 4A  where item  600  is similar to  401 . The target IDs are shown as  601 .  FIG. 7  shows the converted target ID values when the STORport driver is used instead of the SCSIport driver. The information is shown as  700 . 
     It is noteworthy that the present invention maintains and converts target ID values if a user migrates from STORport driver to SCSIport driver. 
     In one aspect of the present invention, a user does not have to manually select or enter target ID values when the user moves from one driver to another. The management application converts the target ID values so that they can be used with the appropriate drivers. 
     Although the present invention has been described with reference to specific embodiments, these embodiments are illustrative only and not limiting. Many other applications and embodiments of the present invention will be apparent in light of this disclosure and the following claims.