Method and system for providing virtualization data services for legacy storage devices

[0001] 1. Field of the Invention

[0002] The present invention relates, in general, to data storage devices and their management including virtualization of the devices, and, more particularly, to a method and corresponding system for providing virtualization data services in a data storage system that includes legacy storage devices with data in place or without disrupting user data on such devices.

[0003] 2. Relevant Background

[0004] An ongoing challenge facing designers and developers of data storage systems is how best to use and integrate existing legacy storage devices with other data storage devices. A legacy storage device is a data storage device that already contains user or application data because it has been used for data storage in the past, such as a host device running an application or as part of an enterprise's data storage system. Problems arise later when attempts are made to include the legacy device in a larger data storage system that includes a variety of management services.

[0005] For example, many data storage systems are managed or configured to provide virtualization features. Virtualization allows a set of storage devices to be pooled together with the combined storage space being regarded as addressable main storage by a user of a data storage system into which virtual addresses are mapped. Presently, when a user allows a data storage system access to a legacy storage device by mapping it to a host or storage manager, the legacy storage device does not support a variety of virtualization features such as volume expansion, snapshot, mirroring, and data migration. Placing metadata or information needed to support these virtualization features on the legacy storage device would destroy the user data stored on the device. As a result, it has proven difficult to fully utilized legacy storage devices that are added to a data storage system with the added devices typically not supporting virtualization and appearing as uninitialized devices or disks to a storage processor.

[0006] In some data storage applications, a storage system may include a “virtualization head” and a set of “captive” storage devices. The storage devices are captive in that they are initially considered raw storage that can be provisioned by the virtualization head. Part of such provisioning that is done by the virtualization head involves the reservation of a configuration metadata region that maintains logs, configuration information, and the like for each storage device in the system, and the data stored in this region on each device facilitates and supports virtualization throughout the raw storage devices. A problem arises because the virtualization head cannot store its configuration metadata region on a legacy device or volume without destroying previously stored user data.

[0007] Another problem is that the data services provided by a data storage manager or processor often require a logging region, a data service-specific metadata region, and a scratch pad region to effectively carry out data management functions. As with the configuration metadata regions, the data storage manager or processor cannot store these regions or their corresponding data on the legacy device without copying over existing user data on a legacy device. The lack of this data seriously affects the use and integration of legacy storage devices into data storage systems, which often results in the legacy storage devices not being effectively utilized and their storage capacities being unavailable to all users of the data storage system.

[0008] Hence, there remains a need for a method and system for more effectively integrating legacy storage devices into data storage systems to enable their pooling with other raw storage devices. Such a method and system preferably would be configured to support at least a portion of the virtualization features presently not available with legacy storage devices such as volume expansion, snapshot, mirroring, data migration, and/or other useful virtualization features.

[0009] The present invention addresses the above and other problems by providing a method and corresponding systems for providing data services including virtualization to legacy storage devices that are added or made available in a storage pool of captive devices. The methods and systems of the invention are adapted to enable generation and management of virtualized volumes for legacy device without destroying user or legacy data stored on the legacy device.

[0010] More particularly, a method is provided for delivering data services such as virtualization to legacy storage devices. The method involves reserving a configuration metadata region (or MDR) in memory of a storage resource that is provided in a storage pool and that is controlled by (or is captive to) a data services platform or storage controller, i.e., an MDR is provided on all captive storage devices. The MDR includes a global set of data containing information used by the data services platform to manage or provide the data services, including virtualization of volumes throughout the storage pool. The method continues with locating a legacy storage device available for use or inclusion in the storage pool, and then, retrieving element information for the legacy storage device from the MDR on the captive storage device(s). A volume (or virtualized legacy volume (VLV)) is built based on the collected element information. The method then includes updating the global set of data in the MDR to include information on the volume built using the legacy storage device element information. The legacy storage device includes memory that stores legacy or user data, but the steps of the method are performed to leave the legacy data unchanged, with volume information stored in the global set of the MDR.

[0011] In some embodiments of the invention, the element information collected for the legacy device may include extent and disk information for the legacy device. The building of the VLV may include building a volume tree and marking the volume tree as a VLV (or flagging the tree) to allow the VLV to be treated differently from other volumes in the storage pool by the data services platform (e.g., no MDR is provided on the legacy device). The method may further include providing a snapshot storage device for the built VLV including updating a metadata region of the snapshot device based on the volume information for the legacy storage device.

[0020] The invention is generally directed to providing a method and system for providing data services such as virtualization to legacy storage devices that contains user or legacy data that is not affected in providing the data services. The inventive method and system provides a data storage system with a data services platform (or storage controller) that manages a storage resource pool of captive storage resources and legacy storage devices. The legacy storage devices are accessible, such as by mapping to a host, but do not as initially provided to the storage resource pool support data services, such as virtualization, controlled by the data services platform because the legacy storage devices do not store or contain metadata used by the data service platform for providing such services to the captive storage resources. According to the invention, the data services platform reserves a configuration metadata region on each of the captive storage resources that contains the definition of the storage system's virtualized storage devices along with the state information for both logical and physical devices (e.g., 128 MB for each device that is extensible using a page reference scheme). A portion of the configuration metadata region provides a global set of definitions for the data storage system (i.e., the global set), and this region is mirrored across at least a subset of the captive storage resources for redundancy.

[0021] The following description describes the method and system of the invention for providing enhanced data services for added legacy storage devices in part by storing configuration metadata for the legacy storage devices in the global set of the data storage system (e.g., stored in the global subset of captive storage resources in each of their global set region of the configuration metadata region of memory). The data services platform or storage controller of the invention includes logic or software (e.g., the platform's configuration management code) is written or adapted to affect the discovery of legacy volumes (or legacy storage devices) such as physically through its driver stacks and/or logically via a scan of the global set configuration metadata region. As will become clear from the following description, the data services platform is also designed to enable the placement of data service specific data regions, logging regions, and scratch pad regions useful for managing the legacy devices on devices other than the legacy device being “virtualized” through the data services platform. To support virtualization and other data services, a virtualized legacy volume (VLV) is created for each legacy storage device in the storage resource pool, and the VLV is a volume that supports data services whose metadata resides on a device other than the legacy device (i.e., in a global set region of a configuration metadata region of a captive storage resource. Significantly, according to the invention, data services are provided to the legacy storage devices via the data service platform and the use of configuration metadata regions in a global set of captive storage resources while leaving the legacy or user data intact on the legacy storage devices and without requiring the user or legacy data to be copied to a virtualized volume.

[0022] In the following discussion, computer and network devices (or “elements”), such as the software and hardware devices within the system 100, are described in relation to their function rather than as being limited to particular electronic devices and computer architectures and programming languages. To practice the invention, the computer and network devices or elements may be any devices useful for providing the described functions, including well-known data processing and communication devices and systems, such as application, database, Web, blade, and entry level servers, midframe, midrange, and high-end servers, personal computers and computing devices including mobile computing and electronic devices with processing, memory, and input/output components running code or programs (“applications”, “tasks” within such applications, and “services”) in any useful programming language, and server devices configured to maintain and then transmit digital data over a wired or wireless communications network.

[0023] Similarly, data storage systems and memory components are described herein generally and are intended to refer to nearly any device and media useful for storing digital data such as disk-based devices, their controllers or control systems, and any associated software. Data, including transmissions to and from the elements of the network 100 and among other components of the network/systems 100, such as between services, typically is communicated in digital format following standard communication and transfer protocols, such as TCP/IP, HTTP, HTTPS, FTP, SCSI, iSCSI, FC, iFC, and the like, or IP or non-IP wireless communication protocols, such as a FC storage system linked via an Ethernet. The invention is particularly suited for use with enterprise storage systems such as those serviced by storage arrays managed by a storage controller and including a plurality of data storage devices or arrays (e.g., disk devices and the like). For example, but not as a limitation, the invention and its features may readily be implemented in a data services platform (DSP) or storage controller, such as the DSP provided in the Sun Microsystems, Inc. StorEdge™ 6920 product or similar products, and an associated storage resource pool including captive or assigned storage devices and one or more added legacy storage device. However, the concepts of the invention are readily applicable to many other storage systems that utilize a storage controller to manage data services such as virtualization in a pool of storage resources or devices such as standard disk arrays.

[0024] FIG. 1 illustrates one embodiment of a data storage system 100 according to the invention. As shown, the system 100 includes a data services platform (or storage controller) 110 that is linked (such as via FC protocol or Ethernet) via digital data communications link 130 to a storage resource pool 140. The storage resource pool 140 may take a number of forms and may be provided in a single array cabinet or in a plurality of cabinets and other devices containing a variety of heterogeneous storage devices or relatively homogeneous storage devices. The storage resource pool 140 includes one or more captive storage resources 150 that may be considered an attached logical unit (ALU) representing a physical device and/or a logical device represented by an identification number or logical unit number (LUN) given to devices connected to a SCSI adapter. Each captive storage resource 150 includes memory 152 storing data 154 and also, significantly, including a configuration metadata region (MDR) 160. Typically, the MDR 160 is allocated and created when a device is configured as “captive.”

[0025] The MDR 160 is an area in memory 152 on each captive ALU that contains information (such as volume and global set information) used by the data services platform 110 to provide data services including virtualization in the storage resource pool 140, e.g., for the captive storage resources 150 and for the legacy storage devices 170. To this end, the MDR 160 is shown to include volume state manager (VSM) object data 162, e.g., partition, parent volume, and other information, and a global set (GS) data 166 including virtualized legacy volume (VLV) data 168. The GS data 166 is an area of the MDR 160 that is global across the pool 140 managed by the data services platform 110. Unlike the VOD 162 which contains information specific to the ALU 150 on which it resides, the GS 166 contains chassis wide information. For example, the specific information in the VOD 162 may include a definition of ALU usage of virtual volume and state and configuration information for those virtual volumes associated with the ALU. The GS data 166 is replicated across a set of the captive storage resources 150 (i.e., a global set of the ALUs 150 with the global set being a subset of the ALUs 150 chosen for redundancy), and the GS data 166 contains VLV data 168. The VLV data 168 represents or defines a virtualized volume with a primary component is a device or ALU without volume and other information used by the data services platform 110 to provide virtualization and other data services.

[0026] Specifically, the storage resource pool 140 is shown to include one or more (such as more than 2 for redundancy purposes) legacy storage devices 170 which are ALUs that do not have a configuration metadata region as provided for the captive resources 150. Each legacy device 170 includes memory 174 with legacy data or user data 176 that remains intact although the device 170 may be virtualized by the data services platform 110. The legacy storage device 170 may be considered a direct access volume (DAV), which is a physical LUN (e.g., an ALU) that does not contain the MDR 160 and that contains data 176 in memory 174 that is mapped to one or more hosts (not shown). To practice the invention, the GS 166 in the MDR 160 of captive storage resource 150 is shown to include the VLV data 168 for legacy storage device 170, and the VLV data 168 may include the DAV information. The provision of the VLV data 168 in the GS 166 on the captive device 150 enables the data services platform 110 to provide virtualization and/or other data services to the legacy storage device 170 by providing a location for persistent storage of state and configuration of the VLV and data services provided for the VLV.

[0027] The techniques for creating and managing a VLV are discussed in detail below with reference to FIGS. 2-8. The VLVs created for the legacy devices 170 can then be accessed through the platform 110 by devices using the storage resource pool 140 for data storage. In addition to virtualization, the platform 110 can provide data service functions such as remote replication and data mirroring that can be applied to these VLVs while preserving the legacy data 176. A user of the system 100 can use the platform 110 for centralized remote replication or for migration on the attached legacy storage device(s) 170 (such as an external device) to add addition capacity to a pool 140.

[0028] The data services platform or storage controller 110 includes a number of functional components that work in conjunction to provide data services to the legacy storage devices 170 (and captive storage resources 150). As shown, the data services platform 110 includes one or more management interfaces 112, which may be implemented with one or more management interface cards (MIC) in some embodiments. The management interface 112 typically includes embedded software that controls the boot of the platform 110 and interacts with the external processors, such as device management software on storage service processors (not shown), that interact with the platform 110. The platform 110 includes a block virtualization mechanism (BV) 114 that controls building or generating new volumes in the system 100 including building new VLVs for legacy storage devices 170. A virtualization configuration manager (VCM) 118 is provided to control changes to the volumes in the system 110. A master virtualization storage processor (MVSP) 120 is provided to function as an interface between a volume state manager database (VSMDB) 126 and ALU information, among other functions. Additionally, the data services functions of the platform or DSP 110 is provided by a volume state manager (VSM) 124 that acts to manage state information for the volume or devices 150, 170 in the storage resource pool 140.

[0029] The operation of each of the components of DSP 110 are explained in detail with reference to FIGS. 2-8, but prior to this discussion, a number of the architectural specifications of one implementation of the invention are provided to better assist one skilled in the art in fully understanding the benefits of the invention. The DSP 110 may be set up to support a particular number of ALUs, such as for example 128 ALUs, that can be designated as VLVs. Each of these VLVs preferably supports (and hence, the VLV data 168 includes any relevant data) the following virtualization features: (a) any volume type using the VLV allows one or more PIT images to be created against them, such as, for example, 8 PITs; (b) data migration with the DSP 110 allowing the data on a VLV to be migrated to a virtual volume that is managed by the DSP 110; (c) local mirroring with the DSP 110 allowing a VLV to be defined as any component of a mirror volume (including mirroring from a VLV to another VLV); (d) mirroring a VLV for an internal volume; (e) multi-path management abstraction with the DSP 110 presenting a VLV as a symmetric volume to host ports (see, for example, FIG. 8); and (f) persistent reservation reserve commands supported by the VLVs.

[0030] In one specific exemplary, but not limiting, embodiment, the VLV data area 168 is a 16 MB area of the 128 MB MDR 160, which is used to store VLV and DAV objects. In this example, this allows for a total of 4096 objects to be contained in the VLV region 168. The number of VLVs supported varies based on how many partitions each VLV contains, but a minimum of 128 VLVs can be supported in this example with the maximum number of partitions in each VLV since the VLV region 168 is mirrored across the global set (or GS subset) of captive storage resources 150.

[0031] The DSP 110 is configured to not write any non-host write data to the ALUs 170 designated as VLV. In other words, metadata regions 160 are not written to the legacy storage devices 170, which are designated as VLVs rather than volumes as are captive storage resources 150. The VLVs among the legacy storage devices 170 do not support extension or stripping data service features. One reason why extension is not supported is that once the VLV is extended the legacy device 170 may contain references to data on other partitions and if the legacy device 170 is removed from the VLV the data may be unusable. The configuration information for VLVs is preferably redundantly stored on storage (such as devices 150) managed by the DSP 110 in the MDR GS. The VLVs preferably support reservations and persistent reservations but are not configured for adoption (e.g., to allow a take-ownership command).

[0032] In some embodiments of the storage system 100, the only type of volume that may be used for VLV creation is concatenated. Typically, there is at least one initialized captive storage resource 150 with a MDR 160 in the storage resource pool 140 (or 2 captive ALUs 150 if redundancy is desired) before a legacy storage device 170 is added as a VLV. If dynamic COW expansion is supported in the system 100, the COW data and log resides on one or more of the captive ALUs 150 since the DSP 110 cannot write to the legacy device 170 (e.g., to a MDR on such as device 170). Persistent reservation metadata information is stored in the VSMDB 126. A legacy device 170 that is part of a VLV as indicated in VLV data 168 cannot be re-used for another volume or DAV. Further, it is preferable in most embodiments of the storage system 100 that a host (not shown) is not allowed to access the legacy devices 170 directly after they are added to a VLV.

[0033] As can be seen from the above description of FIG. 1, a significant change to support VLVs in a storage system is the effective handling of non-captive or non-DSP owned ALUs (i.e., ALUs without a MDR). It is preferable that this challenge be approached such that these ALUs or legacy devices are treated as any other ALU in the storage pool operated by a DSP. In a typical existing storage controller, raw devices such as legacy devices are ignored by the storage controller, e.g., by the VCM and MVSP. For example, when a DAV is added to a target service, the MIC may configure the proper iSCSI connections and set up proper mappings. In contrast for VLVs, the inventors recognize that it will be desirable for the VCM (such as VCM 118 of FIG. 1) to treat raw or legacy devices similar to DSP-owned or captive devices 150 and notify the MVSP 120 when there is a change to any legacy device. In some embodiments, this handled by having the VCM 118 create iSCSI or other communication connections between storage processors (SPs) that contain or control raw or legacy devices. This allows the MVSP 120 to treat the legacy devices as any other ALU (but also has the disadvantage of creating connections for devices the MVSP 120 may not need to access). In more preferred embodiments, the MVSP 120 is configured to recognize when a volume being created is a VLV or at start of day when the VSMDB 126 states there are VLVs. The MVSP 120 requests a list of all non-DSP or non-captive devices (i.e., legacy devices 170) from the VCM 118. The MVSP 120 then adds these devices 170 to its in-memory ALU list. The DSP is typically not allowed to write to any device it discovers that does not have an MDR on it that the DSP recognizes as “its own” until configured to do so by an administrator.

[0034] Another issue with handling of legacy devices 170 that is addressed by the invention is what should the MIC 112 (or user) see once a raw or legacy device 170 is added to a VLV. In some embodiments, a processor where the legacy device 170 is attached would detect that the ALU 170 was being used for a VLV and would report a “fake” slice in response to the disk query. In more preferred embodiments, when a raw or legacy device 170 is added to a VLV, a “fake” DSP-like partition is created on the MIC 112. Then, any time a VLV is seen by a NMS, it creates a “slice” and adds it to the storage resource pool 140.

[0035] FIGS. 2 and 3 illustrate the creation of a simple virtualized legacy volume (VLV). FIG. 2 illustrates a volume tree 200 of a VLV and shows a VLV being created with a single legacy device 230. A first storage processor (SP) 210, such as one provided as a data services platform, is shown to contain a concatenated VLV 214 that is created from a legacy device 230 that is presented by a host or second SP 220 which initially presents the legacy device 230 to the SP 210 as a raw partition or raw device 226. The mapping of the VLV 214 to the host SP 220 should typically not require any significant modification as the VLV 214 acts like any other single partition concatenated volume.

[0036] FIG. 3 illustrates at a high level a method 300 of creating a VLV, such as the VLV 214 of FIG. 2 and such as by operation of the storage system 100 of FIG. 1. As shown, the actions of the method 300 are carried out by portions of a data services platform including a management interface or MIC 310, a block virtualization manager or BV 312, a virtualization configuration manager or VCM 314, a master virtualization storage processor or MVSP 316, and a volume state manager database or VSMDB 318 (typically in conjunction with operation of a volume state manager (VSM) 124 as shown in FIG. 1). At step 321, the MIC 310 locates available ALUs (e.g., all captive and legacy storage devices 150, 170). During 321, the MIC 310 may execute a storage scan that locates all the available storage devices linked to its data services platform or DSP (such as DSP 110 of FIG. 1). In this case, the legacy device(s) show up as an “unitialized” storage device or disk with no slices.

[0037] At 322, the MIC 310 allows the legacy device to be used as the only element of the new VLV and sets the VLV flag in the volume structure to indicate the new volume is a VLV. Further at 322, the MIC 310 issues a volume request to the BV 312. At 323, the BV requests volume element (e.g., ALU) information from the MIC 310 for the legacy device. Then, at 324, the BV 312 uses the ALU information for the legacy device to request extent and disk information from the VCM 314. The method 300 continues at 325 with the BV building the volume tree (see FIG. 2) using the legacy device (such as legacy device 170 or 230), e.g., slice is set at −1, and forwards the tree to the VCM 325. Again, the volume or volume tree is marked as a VLV.

[0038] At 326, the VCM 314 notifies the MVSP 316 of a volume configuration change. The method 300 continues at 327 with the MVSP 316 receiving the request from the VCM 314, and in response, the MVSP 316 requests from the VCM 314 a list of extents associated with the new volume (i.e., the new VLV). The MVSP 316 also requests from the VCM 314 volume information for the new VLV. At 328, the MVSP 316 validates the received extent information and also, verifies that the VLV objects being created do not already exist. This may be accomplished via queries to the VSMDB 318.

[0039] If these validations are successful, the MVSP 316 at 329 creates and writes the VLV database objects to the VSMDB 318. For example, the MVSP 316 may check in-memory (e.g., “alu_arr”) to validate the legacy device. The MVSP may also request a raw or legacy device list from the VSMDB 318 and see VLV flags. As shown, the VSMDB 318 creates or manages a global set 350 of captive storage devices (or captive or DSP-owned ALUs) that have a reserved configuration metadata region (MDR) 340, 360 and within each of these MDRs 340, 360 a global set (GS) 342, 362 is stored including device configuration information, such as volume information and the like, for each device in the storage pool. This global set of information 342, 362 is useful for providing data services such as virtualization, and significantly, is shown to include VLV data 344, 364 that is created as part of the VLV generation process 300. In other words, the global set of information 342, 362 stores configuration and state information persistently. At 330, the MVSP 316 sends the volume tree and creation response to the VCM 314. After successful completion of the VLV generation 300, a “show volume” request or instruction may result in a volume name (such as vol/vlv and/or disk/4/3/2/0 or the like), a volume type (such as SAN or the like and/or concatenated), a volume size (such as a listing of the available storage space), a volume state (such as free, online, and the like), and a condition of the VLV (such as “intact” or the like).

[0040] FIGS. 4 and 5 illustrate the creation of a VLV with a legacy device with the snapshot data services feature. FIG. 4 illustrates a volume tree 400 for a VLV with a dynamic COW pool, and FIG. 5 illustrates a method 500 for creating such a VLV. In one embodiment, a legacy device 450 (such as a 17.09 GB legacy device or the like) is made accessible via a host storage processor 440, and the VLV and dynamic COW pool created based on the legacy device 450 are the size of the legacy device 450. The volume tree 400 is shown to include a storage process (SP) or DSP 410 with a concatenated volume or VLV 412 along with a point in time image (PIT) or snapshot volume or VLV 416. These volumes are made available via a snapshot SRC 420 that includes a snap partition 422 mapped to a raw partition 424, a snapshot COW 426, and a snapshot log 428. The snapshot COW 426 and snapshot log 428 are mapped to a dynamic COW ALU 430 with a MDR 434 but in some cases the COW 426 and log 428 may be separate ALUs. A communication link (e.g., an iSCSI link) 442 is provided to the logic/processor hardware 448 of the host SP 440 that is providing the legacy device 450 to the storage pool controlled by SP 410. Note, the dynamic COW pool 430 is not provided on the legacy device 450, which prevents alteration or damage of existing legacy or user data, and in some cases the legacy device 450 may also be connected to the snapshot SRC 420.

[0041] FIG. 5 illustrate creation 500 of a VLV with snapshot. The components of a DSP responsible for performing the creation method 500 are shown and include a MIC 510, a BV 512, a VCM 514, a MVSP 516, and a VSMDB 518. At step 521, the MIC executes a storage scan that locates all the available storage devices linked to the DSP (such as devices 150, 170 linked via link 130 to DSP 110 as shown in FIG. 1). For example, a legacy device (such as device 170 or 450) shows up in the storage scan as an “uninitialized” disk or device with no slices. At 522, the MIC allows the located legacy device to be used as the first element of the VLV and sets the VLV flag in the volume structure. Since this volume is a VLV, the MIC verifies that there is space for the desired dynamic COW pool on a different ALU, i.e., on a captive or DSP owned storage device. Also, at 522, the MIC issues a volume request to the BV 512.

[0042] The method 500 continues at 523 with the BV 512 requesting or getting element information regarding the legacy device and additional/different ALU for the volume from the MIC 510. The BV 512 checks applicable snapshot rules and validates that the elements conform to snapshot rules for VLV. At 524, the BV 512 requests extent and disk information for the applicable ALUs from the VCM 514, and then, at 525, the BV 512 validates the legacy device and additional/different storage device or captive ALU. The BV 512 then builds the volume tree (see tree 400 of FIG. 4) using the legacy device (see device 450 or device 170) and the ALU selected to be the dynamic COW ALU. The BV 512 then forwards the volume tree, which is marked as VLV tree, to the VCM 514.

[0043] The VCM 514 responds by forwarding the request to the MVSP 516 at 526. The method 500 continues at 527 with the MVSP 516 getting extent and volume information from the VCM 514. At 528, the MVSP 516 verifies the extent and partition information such as with comparison with volume object data (VOD) 540 in the MDR 540 of the dynamic COW or snapshot ALU. At 529, the MVSP 516 interacts with the VSMDB 518 to update the VOD 542 on the snapshot ALU (see ALU 430 of FIG. 4 or one of the resources 150 in FIG. 1) with the COW and log partitions. The MVSP 516 also creates and writes VLV objects to the VLV database, e.g., VSMDB 518 or a portion of VSMDB 518. Again, a global set of ALUs (or captive resources such as resources 150 in the storage pool) 560 are updated such that their reserved metadata regions 550, 570 include a global set of data 552, 572 that shows the updated VLV region 558, 578 showing the creation of the VLV for the particular legacy device (such as device 450 or 170). As part of 529, the MVSP 516 requests raw or legacy device information from the VCM 514 and then, builds the volume tree, with a VLV tag. At 530, the MVSP 516 returns the volume tree and creation status to the VCM 514.

[0044] FIG. 6 illustrates how a DSP, such as DSP 110 of FIG. 1, may operate to delete a VLV and particularly, a VLV with an associated dynamic COW pool from a storage resource pool. The VLV deletion method 600 is shown again to be performed by a MIC 610, a BV 612, a VCM 614, a MVSP 616, and a VSMDB 618 of a DSP (not shown in FIG. 6 but see platform 110 of FIG. 1). At 621, the MIC 610 sends a volume delete request to the BV 612. The BV 612 at step 622 at to get extent information from the VCM 614. The BV 612 then updates extent information and passes the updated volume information (e.g., updated volume tree) and updated extents to the VCM 614 along with the delete request. At 623, the VCM 614 forwards the delete request to the MVSP 616.

[0045] At 624, with interaction with the VSMDB 618, the MVSP 616 locates associated ALU information and updates the VOD 646 (or dynamic COW pool VOD) in the MDR 642 of the snapshot ALU 640. At 625. Again, the storage pool includes a global set of ALUs that each have a set aside configuration metadata region (MDR) 650, 660 with a global set of data used for data services 652, 662 including a VLV region 654, 664, as the information for use in providing data services by the DSP is not placed on the legacy device corresponding to the VLV. At step 625, the MVSP 616 removes VLV object(s) affected by the VLV delete request from the VLV region 654, 664 of the global set 652, 662 of the MDRs 650, 660 in the global set of ALUs 670. At 626, the MVSP 616 returns the volume deleted status to the VCM 614.

[0046] FIG. 7 illustrates a VLV restoration process 700 performed by a data services platform (DSP), such as DSP 110 of FIG. 1, when the DSP is booted and a VLV was previously created in the storage system or storage resource pool. Again, the DSP includes an MIC 710, a BV 712, a VCM 714, a VSM and MVSP 716, and VSMDB 718 to perform various functions during the VLV restoration 700. At step 721, when the DSP is booted, the VCM 714 is initialized (e.g., at run level 3 on the NINE). At 722, the VCM 714 selects a MVSP 716, and sets up connections (e.g., iSCSI connections) to any DSP-owned or captive resources or ALUs that the MVSP 716 cannot see in the resource pool. At 723, the VCM 714 builds a list of all the captive ALUs in the storage pool (e.g., on the chassis or the like) and sends the ALU list to the VSM/MVSP 716 along with a request to build volume trees.

[0047] The method 700 continues at 724 with the MVSP 716 receiving the device list and then, walking the list to build an in-memory ALU list or database 730. At 725, the MVSP 716 builds the volume trees 750 from this list which is stored in a device in the metadata region 740 as VOD 742, and then, updates the in-memory tree database 750 via VSMDB 718. At 725, the MVSP 716 checks the VLV database for VLV information by inspecting the VLV region 754, 764 of the global set or region of data 752, 762 in the MDRs 750, 750 of the global set of captive or DSP-owned storage resources 770. The MVSP 716 sees that one or more VLV exist in the storage pool and, in response, the MVSP 716 requests a list of raw devices from the VCM 714. Using the VLV regions 754, 764 of the MDRs 750, 760 and applicable ALUs, the MVSP 716 builds the VLV volume tree(s). At 726, the MVSP notifies the VCM 714 that the image is built and that there are extent and volume changes. At 727, the VCM 714 queries the MVSP 716 for extent and volume information builds it own copy of the volume trees.

[0048] In preferred embodiments of the invention, VLVs are configured to support multi-path features as the case with other volumes formed for a DSP-owned or captive storage resource or device. These multi-path features include symmetric access from multiple host ports among other features. FIG. 8 illustrates a multi-path volume tree for a single device VLV (e.g., a VLV formed based on legacy device 860) that is mapped to a host 810 with multi-path support. The VCM in the DSP configures the proper connections, e.g., multi-path iSCSI link 848. As shown, the two paths are provided to the legacy device 860 to storage processors 840, 850 with link 848 connecting logic/hardware 854 of storage processor 850 with MP 846 of storage processor 840. Symmetry is provided in the system 800 as host 810 can access the virtualized legacy volume provided by legacy device 860 via concatenated VLVs 824, 836 provided by storage processors 820, 830, which each are mapped to the raw partition 842 maintained by storage processor 840.

[0049] Although the invention has been described and illustrated with a certain degree of particularity, it is understood that the present disclosure has been made only by way of example, and that numerous changes in the combination and arrangement of parts can be resorted to by those skilled in the art without departing from the spirit and scope of the invention, as hereinafter claimed.