Is there a way to list the VVs exported to a hostset using the CLI? I'm trying to untangle our mess of exports, to corral them into a single VVset/Hostset configuration.
Mainly, I want to compare which VVs are exported to a host directly vs. through the use of a hostset.
How do I list VVs exported to hostset using CLI?
Re: How do I list VVs exported to hostset using CLI?
Did you have a look at showvlun already?
The goal is to achieve the best results by following the clients wishes. If they want to have a house build upside down standing on its chimney, it's up to you to figure out how do it, while still making it usable.
- Richard Siemers
- Site Admin
- Posts: 1333
- Joined: Tue Aug 18, 2009 10:35 pm
- Location: Dallas, Texas
Re: How do I list VVs exported to hostset using CLI?
Yeah showvlun will be your command.
I recommend against using both hostsets and vvsets together. I prefer to stick to just host sets, and avoid vvsets, reason being is greater control over lun # assignments.
I also recommend a good VV naming standard. We use hostname_LUN#_briefdescription, and we make sure the export matches the LUN# we labeled. This works really well for requests to grow/decommission a lun, makes it quick and easy to find the exact target to grow/decommission.
examples:
NTEXCHANGEP1_1_DAG1
AIXORACLEP1_7_ASM
AIXORACLEP1_1_ORAvg
NTSQLP1_44_HR.DB
NTSQLP1_45_HR.LG
NTSQLP1_46_FIN.DB1
NTSQLP1_47_FIN.DB2
NTSQLP1_48_FIN.DB3
NTSQLP1_49_FIN.LG1
Its not 100% fool proof, we have had times where a team will request 2 luns of the same size, we will provision it and say LUN44 is for your database files, and LUN 45 is for your log files, but OS teams/dba's can still get it backwards. So the description piece at the end is an optional convenience, and the LUN# should be primary identification used when communicating an action with the host admins.
The descriptions I use allow us to better leverage system reporter to run filtered reports by limiting the report to just LUNs by wildcards in the name.
I recommend against using both hostsets and vvsets together. I prefer to stick to just host sets, and avoid vvsets, reason being is greater control over lun # assignments.
I also recommend a good VV naming standard. We use hostname_LUN#_briefdescription, and we make sure the export matches the LUN# we labeled. This works really well for requests to grow/decommission a lun, makes it quick and easy to find the exact target to grow/decommission.
examples:
NTEXCHANGEP1_1_DAG1
AIXORACLEP1_7_ASM
AIXORACLEP1_1_ORAvg
NTSQLP1_44_HR.DB
NTSQLP1_45_HR.LG
NTSQLP1_46_FIN.DB1
NTSQLP1_47_FIN.DB2
NTSQLP1_48_FIN.DB3
NTSQLP1_49_FIN.LG1
Its not 100% fool proof, we have had times where a team will request 2 luns of the same size, we will provision it and say LUN44 is for your database files, and LUN 45 is for your log files, but OS teams/dba's can still get it backwards. So the description piece at the end is an optional convenience, and the LUN# should be primary identification used when communicating an action with the host admins.
The descriptions I use allow us to better leverage system reporter to run filtered reports by limiting the report to just LUNs by wildcards in the name.
Richard Siemers
The views and opinions expressed are my own and do not necessarily reflect those of my employer.
The views and opinions expressed are my own and do not necessarily reflect those of my employer.