Find all available LUN IDs for a given IGroup

[NEBOJSA_ILIC]

Hi,

I'm working on a simple Volume/LUN creation/mapping workflow and would like to find all available LUN IDs in the range 0-255 (for mapping to VMware hosts) for a given IGroup. The idea is to use this list as a User Input, so that a user can select from this list when mapping the LUN to an IGroup.

I've managed to write a simple MySQL query to return LUN IDs which are already used, but don't know how to return all the other values in the 0-255 range which aren't 

Thanks for your help.

BR,

Nebojsa

[dhruvd · Accepted solution]

Hi Nebojsa,

In order to achieve your objective of listing available LUN IDs for a given igroup, you would have to create a table with entries from 0-255 and then perform a diff of the lun map table against this one. Following steps will help you achieve that:

1. Login to your mysql database as the 'wfa' user. Create a table, say 'all_ids' with just a single column called 'id', in the playground database:

CREATE TABLE `all_ids` (

  `id` mediumint(8) unsigned NOT NULL auto_increment,

  PRIMARY KEY (`id`)

) AUTO_INCREMENT=1;

2. Populate this table with values from 0 to 255. I have short procedure for this which i can share if required.

3. Use the following sql query for your user input, that will return ids in the range 0-255 which have not been used to map against that specific igroup.

SELECT avail_ids.id

FROM

playground.all_ids AS avail_ids

LEFT JOIN

(

    SELECT storage.lunmap.lun_map_value

    FROM

    storage.lunmap JOIN storage.igroup

    ON storage.lunmap.igroup_id=storage.igroup.id

    WHERE

    storage.igroup.name = '${igroup_name}'

)  AS temp    

ON avail_ids.id=temp.lun_map_value

WHERE temp.lun_map_value IS NULL

OR

avail_ids.id<>temp.lun_map_value

Note: I have made use of a variable ${igroup_name}. Please replace this with the variable you are using to identify the igroup_name.

         This is a query that will work with the storage scheme. If you are working with clusters, you will have to replace the scheme names in this query to cm_storage.

Let me know if any other help with this required.

Regards,

Dhruv

[JGPSHNTAP]

This is an interesting topic.. I've done this before with straight powershell for netapp to determine which lunID's are mapped to igroup and lun.

I like how you did the mssql piece

[NEBOJSA_ILIC]

Hi dhruvd,

thanks, this works like a charm The only problem I have now is that after creating and deleting LUNs, WFA somehow fails to update this information.

E.g. I have created a few test volumes and LUNs, so the first available LUN ID became 11. I then deleted all of these volumes/LUNs, and just be sure I'm not working with cached values - reset Scheme on my UFM data source and did a manual  acquisition, but when I run the workflow it still displays 11 as the first available LUN ID. When I run the SQL script used to display User Input against the WFA database, it returns correct values as available LUN IDs.

Does anyone have an idea what could be the problem? I'm running WFA 2.2.0.2.4RC1.

Thanks and BR,

Nebojsa

[dhruvd]

Hi Nebojsa,

I have a couple of questions:

1. Were the volumes/LUNs created earlier using a workflow in WFA?

2. Were these deleted using a workflow in WFA?

In case these were

created using WFA, and *not* deleted using WFA,

or

not created using WFA, and not deleted using WFA,

the reason would be:

1. The UM database is not updated.

2. As a result the WFA cache still assumes that the LUN is present on the storage system, but has not received the updated information from the UM database.

A monitor refresh from UM against the storage system before manual acquisition should fix this issue.

Regards,

Dhruv

[NEBOJSA_ILIC]

Hi dhruvd,

my case is "created using WFA, and *not* deleted using WFA"

I couldn't find a way to do a monitor refresh through UM (I'm using UM for cDOT 6.0), but after a few days workflow presents correct information. After two days first available LUN ID became 4, and then after 2 more days the offered user input started matching the state on the storage system, so it seems as a cache issue.

BR,

Nebojsa

[dhruvd]

Hi Nebojsa,

You got it right, it's because of the data present in the WFA cache.

Let me explain what happens.

When WFA creates a new object on a cluster, it caches these details until it gets these details about the new object from the UM that is monitoring the cluster.

What has happened with your WFA is, it has cached details of the created LUN.

Now, after the deletion of the objects from the cluster, UM has not yet refreshed the object details from the cluster. As a result of this, even after a manual acquisition, WFA continues to have stale data from UM.

Quick resolution would be to either :

1. Wait for UM to acquire fresh details from the cluster. UM 6.0 by default, automatically refreshes data from each cluster at regular intervals. And once this is done, perform a manual acquisition against The UM data source.

2. Or, manually delete the reservation entries of the newly created volumes or LUNs from the Reservations page.

Hope this helps.

Regards,

Dhruv